The static structure

The following Figure 1, “ IIIMSF static structure. ” shows the static structure of IIIMSF in UML.

Figure 1.  IIIMSF static structure.

IIIMSF static structure.

Approximately, the static structure consists of the following three parts:

  1. protocol handler

  2. main part (manages the current IM information)

  3. LE interface part.

  4. scheduler

Refer to Figure 1, “ IIIMSF static structure. ” about what structure is correspond to each of the above part.

In the following sections, I explain those major parts of IIIMSF one by one.

protocol handler

The protocol handler of IIIMSF manages all of the communications related to the protocol, and actively invokes the interfaces provided by the main part.

The protocol handler also manages all states related to the protocol. It must properly send and receive messages to communicate with clients. IMProtocol, IMState and ICState abstract classes keep the current state of the protocol. Their corresponding IIIMProtocol, IIIMP_IMState and IIIMP_ICState classes actually manage the IIIMP-specific data and methods.

IMProtocol and IIIMProtocol classes provides the direct entry interfaces, which are used by IMScheduler, and properly create IMState object by negotiating with the main part via IMAccept interface. In addition, IMProtocol has a message dispatcher that receives a message and then pass it to a IMState object.

IMState and IIIMP_IMState classes manage all of the state related to Input Method handle. By negotiating with the main part via IMHandler interface, it manages creation and annihilation of ICState. Besides it, IMState deals with client's request that is independent of IC, and delegate it to the main part via IMHandler.

ICState and IIIMP_ICState classes manage all of the state related to Input Context handle. They actually deal with client's request of the Input Context to which the ICState corresponds.

ICState and IIIMP_ICState classes manage all of the state related to Input Context handle. They actually deal with client's request of the Input Context to which the ICState corresponds.

scheduler

The scheduler is defined as IMScheduler and its subclasses (currently, only IMScheduler_MTPC is available).

IMScheduler manages the execution thread and concurrency policy. It recevies only IMProtocol and IMState objects. By using such objects' interfaces, IMScheduler determines how to process the next task. IMScheduler_MTPC(MTPC means Make a Thread Per Connection) is one of the implementation of IMScheduler. It allocates one thread for one IMState.

The scheduler part occupies a small portion of IIIMSF, but it is a crucial part, for it rules the concurrency policy of IIIMSF.

main part

The main part manages all of the informations of currently effective clients, e.g, connection, desktop, user, context, .etc.

This part accepts requests from protocol handler, and properly directs LE to process those with LE interface part. The main part also determines which LE processes them.

From the perspective of the protocol handler, the main part works as a passive object. It is the important characteristic. In other words, the main part does not issue any method invocations without requesting it via IMAccept, IMHandler, and ICHandler. These three are the public interfaces of the main part.

In the following subsections, we will explain the essential classes of the main part one by one.

Connection management

IIIMSF starts by start method of IMSvr class, which is initialized at the startup, and creates an LEMgr (see the subsection of LE management) and an IMProtocol (actually creates a IIIMProtocol object in the current implementation), then initializes them by looking up the configurations (from command line argument, configuration file, or something else. These informations are encapsulated by IMSvrCfg and its subclasses. Notice that they are not shown in the static structure diagram so that refer to the source code for detail).

IMSvr object provides IMAccept interface, actually it is implemented by the abstract superclass of IMSvr, but it is not a limitation. The protocol handler must forward the incomming request of new connection establishment to IMAccept interface. IMSvr checks it by authenticating the request, and if it is passed, IMSvr create IMConnection object for the new connection.

One IMConnection object represents one connection. IMSvr assigns the incomming connection to a newly created IMConnection object. IMConnection provides IMHandler interface. IMSvr pass it to the protocol handler via IMAccept interface.

User management

IMUser encapsulates each user's information. IMUser object will be created per one user that is currently connected to the server.

Inevtitably, the creation of IMUser cannot be separated from the authentication system. IMUserMgr class handles user authentication, and create a new IMUser object when it accepts the credential sent from a client.

Since IMUser can be related to the multiple connection (note that each connection is represented by IMConnection object), IMConnection object have a reference to one IMUser object, but currently, IMUser has no direct references to IMUser object, which can be 1:n mapping.

Input context management

The protocol part requests a new input context to the IMConnection object via IMHandler interface. The IMConnection object creates a new IMInputContext object, which represents a created input context, and pass the ICHandler interface provided by the object to the protocol part.

Since IMInputContext instance represents an actual entity of input context, it naturally has one or more contexts managed by language engine(s), which are represented by LEContext instance.

LEContext instance is created by LEBase instance, i.e., it is so-called prototype pattern. LEMgr chooses the best candidate of LEBase by inspecting attributes of the LEContext instance, then create a LEContext instance from the LEBase instance. For the detail of LEBase and its manager, LEMgr, refer to the section called “ Language Engine management ”.

Language Engine management

When initialing internally, htt_server list up the currently available language engines, which is done by LEMgr instance. LEMgr is initialized by the IMSrv instance.

LEMgr provides approximately two sorts of services; (1) available input methods and languages; and (2) choose an language engine (actually, it is an LEBase instance) by the given predicate.

IMInputContext choose the best candidate of LEBase instances for the sake of LEMgr, and then create LEContext as discussed so far.

LE(Language Engine) interface part

LE interface part sends events dispatched from the main part, and provides functionalities to LEs.

LE interface part informs each LE of function pointers to generate and execute IML instruction. LE can utilize them to respond to sent events.

IML instruction is a abstract data to encapsulate actual behaviors of an input method. Executed IML instructions are queued by IMLExec object, and properly dispatched to clients by the protocol handler.