Transaction command types used by Socket Frontend/IMEngine/Config, Helper and Panel.
This commands are used in communication protocols of SocketFrontEnd, SocketIMEngine, SocketConfig, Helper and Panel.
There are mainly four major protocols used in the communications among each part of SCIM:
- between SocketFrontEnd and SocketIMEngine (SocketFrontEnd is server)
- between SocketFrontEnd and SocketConfig (SocketFrontEnd is server)
- between Panel and FrontEnds (eg. X11 FrontEnd, Gtk IMModule and QT IMModule. Panel is server)
- between Panel and Helper (Panel is server).
As soon as the socket to the server is established, the client must call function scim_socket_open_connection() to create the connection and get the magic key for later communication.
At the same time, the server must call function scim_socket_accept_connection() to accept the connection and get the same magic key for later client verification.
The valid types of servers are:
- "SocketFrontEnd"
The socket FrontEnd server provides remote IMEngine and Config services. It accepts "SocketIMEngine" and "SocketConfig" clients.
- "Panel"
The Panel server provides GUI and Helper management services. It accepts "FrontEnd" and "Helper" clients.
The valid types of clients are:
- "SocketIMEngine"
The socket IMEngine client acts as a proxy IMEngine forwarding all requests to SocketFrontEnd. It can only connect to "SocketFrontEnd" server.
- "SocketConfig"
The socket Config client acts as a proxy Config forwarding all request to SocketFrontEnd. It can only connect to "SocketFrontEnd" server.
- "FrontEnd"
If a FrontEnd needs a Panel GUI services, it'll be a "FrontEnd" client of the Panel. It can only connect to "Panel" server.
- "Helper"
All Helper objects should be "Helper" clients of a Panel. It can only connect to "Panel" server.
Then the client and the server can communicate with each other via the socket by sending transactions.
Multiple commands and their data may be put into one transaction with a restricted order. The data of a command must be put into the transaction just follow the command itself.
A transaction sent from a socket client to a socket server (eg. SocketIMEngine to SocketFrontEnd) must be started with a SCIM_TRANS_CMD_REQUEST command followed by an uint32 magic key of the client (returned by scim_socket_open_connection() function.
A transaction sent back to a socket client from a socket server must be started with a SCIM_TRANS_CMD_REPLY command.
So for example, the layout of a transaction sent from SocketIMEngine to SocketFrontEnd may look like:
Some commands may be used in more than one protocols for similar purpose, but they may have different data in different protocol.
Brief introduction of communication protocols used in SCIM:
Please refer to the descriptions of each Transaction commands for details.
- Protocol used between SocketIMEngine and SocketFrontEnd
In this protocol, SocketFrontEnd is socket server, SocketIMEngine is client.
- Protocol used between SocketConfig and SocketFrontEnd
In this protocol, SocketFrontEnd is socket server, SocketConfig is client.
- from SocketConfig to SocketFrontEnd:
The Transaction sent from SocketConfig to SocketFrontEnd must start with SCIM_TRANS_CMD_REQUEST and followed by an uint32 magic key which was returned by scim_socket_open_connection() and scim_socket_accept_connection().
Before parsing the Transaction, SocketFrontEnd must verify if the magic key is matched. If the magic key is not matched, then SocketFrontEnd should just discard this transaction.
There can be one or more commands and corresponding data right after the magic key.
The valid commands which can be used here are:
- from SocketFrontEnd to SocketConfig:
The Transaction sent back from SocketFrontEnd to SocketConfig must start with SCIM_TRANS_CMD_REPLY and end with SCIM_TRANS_CMD_OK or SCIM_TRANS_CMD_FAIL to indicate if the request previously sent by SocketConfig was executed successfully.
For some requests, like SCIM_TRANS_CMD_FLUSH_CONFIG, etc. no result data will be returned.
For some requests, like SCIM_TRANS_CMD_GET_CONFIG_STRING, etc. the corresponding data will be returned between SCIM_TRANS_CMD_REPLY and SCIM_TRANS_CMD_OK commands.
- Protocol used between FrontEnds and Panel
In this protocol, Panel (eg. scim-panel-gtk or scim-panel-kde) is socket server, FrontEnds are clients.
- Protocol used between Helper and Panel
In this protocol, Panel (eg. scim-panel-gtk or scim-panel-kde) is socket server, Helper is client.
- from Helper to Panel:
The Transaction sent from Helper to Panel must start with SCIM_TRANS_CMD_REQUEST and followed by an uint32 magic key which was returned by scim_socket_open_connection() and scim_socket_accept_connection(). Before parsing the Transaction, Panel must verify if the magic key is matched. If the magic key is not matched, then Panel should just discard this transaction.
There can be one or more commands and corresponding data right after the magic key.
The valid commands which can be used here are:
- from Panel to Helper:
The Transaction sent from Panel to Helper must start with SCIM_TRANS_CMD_REPLY and followed by an uint32 input context id and a scim::String input context UUID. Then there can be one or more commands and corresponding data just after the UUID.
The valid commands which can be used here are:
| const int scim::SCIM_TRANS_CMD_OPEN_CONNECTION = 5 |
This command is used internally by scim_socket_open_connection() and scim_socket_accept_connection().
It's sent from a socket client to a socket server to request the server to create the connection.
The corresponding data are:
- (scim::String) a version string (the binary version of SCIM).
- (scim::String) type of the client, eg. "SocketIMEngine", "FrontEnd", "Helper" etc.
If the socket server accept the connection request, it must send back a Transaction with following content:
- SCIM_TRANS_CMD_REPLY
- (scim::String) a comma separated server types which are supported by the server, eg. "SocketFrontEnd" etc.
- (uint32) a magic key used to validate the communication later.
Then if the client accept the result too, it must send the following content back to the socket server:
Otherwise, the client must return:
If the socket server do not accept the connection in the first stage, it should discard the request and send nothing back.