Overview of the LiMo Messaging Plug-ins

Plug-ins Classifying Plug-ins

There are two dimension to classify plug-ins. The first dimension classifies the plug-in according to the following two categories:

Framework, defined in framework_plug-in directory
Service-specific, defined in msg_plug-in directory

A plug-in must below to one of these categories. The second dimension calssifies the plug-in by the modules that the LiMo Messaging Framework provides for applications:

Filter (only in Framework)
Transport (only in Framework)
Storage (in both Framework and Service-specific)

These categories are described in the following sections.

The next figure shows the messaging system and the role of the Messaging Framework, plug-ins and applications in creating and receiving messages.

Messaging System Architecture

Filter Plug-in

There are two groups of functionality that filter plug-ins provide:

Defining and implementing concrete filter rule. This is used by applications.
Checking filter rule functions. This is used by the framework to check application's filter rules and decide how to dispatch the incoming messages.

The filter plug-in will be invoked in the framework once MAPI Session-related API is invoked. For more information on MAPI Session-related API, please refer to Message sending and receiving . The definition of this interface is in Msg_Plugin_Filter_Interface.h

Transport Plug-in

The transport plug-in is a bridge between the framework and the network. There are two occasions when this plug-in is used:

The framework gets the network events from transport plug-in, then notify applications. It is responsible for notifying framework when a network event occurs.
The framework gets the requests from applications, then sends them to transport plug-in. The transport plug-in is responsible for translating the requests from the framework, then sending them to network (or other components) to get the corresponding service (e.g. send a SMS.)
The transport plug-in will be invoked in the framework once MAPI Session-related API is invoked. For more information on MAPI Session-related API, please refer to Message sending and receiving .
The definition of this interface is in Msg_Plugin_Transport_Interface.h

Framework Storage Plug-in

The framework storage plug-in provides the storage related functionality, such as adding, updating, deleting, querying, counting, moving and getting common information of messages, accounts and folders. This common information is a collection of the generic information from each service-specific message plug-in storage, such as SMS, MMS, Email, and i-Mode messaging. The detail data will be stored in service-specific message storage plug-in. Please refer to Message storage plug-in.
The purpose of creating the common information is for improving performance. The functions, such as adding, updating, deleting, moving data, in framework storage plug-ins will be called by message storage plug-in's corresponding functions to synchronize common information. The other functions of Framework Storage Plug-in, such as querying and sorting, will be called directly by MAPI Storage corresponding methods for performance reasons.
The definition of this interface is in Msg_Framework_Storage_Interface.h.

Message Storage Plug-in

Each service-specific message storage plug-in provides the service-specific storage related functionality, such as adding, updating, deleting, moving and getting detail information of messages and accounts. Each service-specific message storage plug-in has its own detail information of message and account.
The purpose of creating the service-specific message detail information is to store the service-specific data.
For example, the SMS storage plug-in has the specific knowledge on SMS format, and additional data that generic message structure does not cover. Each function of the message storage plug-in will be called by the corresponding functions in MAPI storage APIs. The functions in message storage plug-in, such as adding, updating, deleting, and moving data, SHOULD call framework storage plug-in's corresponding methods to synchronize common information.
The definition of this interface is in Msg_Plugin_Storage_Interface.h.

Storage Registry

Registry file information has the following format:

[Groupname] 
mediatype= 
storeId= 
canDeregister= 
name= 
path=

Groupname is the group name for this configuration information. It collects the following information to associate it with a specific item of registry.
mediatype is an integer. It indicates the type of storage media location.
storeId is a unique storage identifier.
canDeregister is an integer. Valid values are: 0 for can deregister and 1 for cannot deregister.. Indicates whether or not the storage can be deregistered.
name is a string. It indicates the name of the storage.
path is a string. It indicates the full path of the storage location.

The media type 1 for flash and media type 2 for SIM is defined in the following example:

[storage-registry-item1] 
mediatype=1 
storeId=2 
canDeregister=0 
name= *** 
path=/usr/local/... 
[storage-registry-item2] 
mediatype=2 
storeId=1 
canDeregister=1 
name= *** 
path=/usr/local/...

There is only one storage registry file. All storage id information shall be written into it. Application developers MUST predefine standard storage ids and write the supported storage information into the storage registry file.
When an application calls MsgListStorageRegistry or MsgGetStorageRegistry (see Messaging API [2]) the messaging framework will receive this command. Then the messaging framework will load and parse this storage registry file and return the result to the application.

Storage Subsystem

The following diagram represents the storage subsystem architecture.

Storage Subsystem Architecture Option 1

Alternately, you can combine the framework storage plug-in and the message storage plug-in into one, as the diagram below shows.

Storage Subsystem Architecture Option 2

Plug-in Configuration

Plug-in developers MUST provide a plug-in configuration file in the following format:

[Groupname] 
type= 
name= 
capability= 
alive= 
language= 

queryrule= 
sorttype=

Note: queryrule and sorttype are used only for framework storage plug-in configuration. The rest of the fields are for all plug-ins.

Groupname is the group name for this configuration information. It collects the information below and assigns it to one plug-in. The Groupname can be regarded as a separator between two plug-ins' configuration information.
type indicates the plug-in's type. It is an integer. (1 for transport plug-in, 2 for filter plug-in, 3 for framework storage plug-in, 4 for message storage plug-in)
name is a string that represents the full path of the plug-in. It tells framework where to find the plug-in.
capability indicates the capability of the plug-in. For transport and message storage plug-ins it indicates what message type this plug-in supports. Message types must be defined in the following manner: mainType:subType, with message types separated by comma. For filter plug-ins, it indicates what filter types the plug-in supports. Normally, it is a string list separated by commas.
alive indicates whether or not the framework shall unload the plug-in after use. It is an integer. (0 for unload after use; 1 for always alive)
language is a string value, indicating the programming language in which the plug-in is implemented. The supported values are c and cpp.
queryrule is a string that indicates which query ids will be supported. Normally, it is a string list separated by commas.
sorttype is a string that indicates which sort types will be supported. Normally, it is a string list separated by commas.

The following example defines the SMS message type MSG_MESSAGE_TYPE_SMS as 2, sub type MSG_MESSSAGE_TYPE_TEXT is 0, MSG_MESSSAGE_TYPE_PORT is 1.

[limo-transport-sms] 
type=1 
name=/usr/lib/libsmstransprovider.so 
capability=2:0,2:1 
alive=0 
language=c

Suppose a filter plug-in supports the following filter ids: 1, 2, 3, 4, and 5. The configuration item should look like the following:

[limo-filter] 
type=1 
name=/usr/lib/libfilter.so 
capability=1,2,3,4,5 
alive=0 
language=c

There is only one plug-in configuration file. All plug-ins' information shall be written there.
When the framework is initialized, it loads and parses this configuration file, then loads and manages all the required plug-ins according to the information in the file. The framework gets the capability of each plug-in, and dispatches messages, requests and other actions to the proper plug-in according to their types and capabilities.

Plug-in Interfaces

The following table describes the interfaces that plug-in developers must implement.

	Framework Storage (framework_plugin)	Message Plug-in (msg_plugin)
Message Filter		Msg_Plugin_Filter_Interface.h
Message Transport		Msg_Plugin_Transport_Interface.h
Storage, Message and Account	Msg_Framework_Storage_Interface.h	Msg_Plugin_Storage_Interface.h

Generated on Mon Mar 31 01:01:00 2008 by

1.5.4