This section provides an overview of the functionality and the architecture of the Messaging Framework collection.
Messaging Framework allows client applications to access the functionality of installed plug-in modules through a common interface. This allows client applications to be designed without foreknowledge of the message protocols that may later be used.
In ROM, Messaging Framework consists of the Message Server executable msexe.exe and two framework DLLs msgs.dll , mtur.dll . At run-time, messaging clients use APIs from the framework DLLs to access the frameworkâs functionality.
Based on two main concepts explained above, Messaging Framework offers the following functionality:
Functionality to manipulate the set of plug-in modules
The Message Type Module (MTM) architecture allows plug-ins to add support for new message types. All interactions with lower-level communication protocols, for example TCP/IP or SMS stack, are performed by the plug-in modules. The set of installed plug-in modules can be changed by installing a new plug-in or removing an installed plug-in. Plug-in modules are identified by their name. Messaging Framework requires a new plug-in module to provide registration data such as its name, version number and function entry points. For an example of a plug-in registration file, see MTM resource file .
Functionality to store message entries
Messaging Framework provides the functionality to store message entries, index data, a set of streams and binary files. For information, see Types of Storage for a Message Entry .
Functionality to navigate the tree of message entries
Messaging Framework provides the tree view of message entries. The tree has a root entry. The children of the root entry must be entries of type service. The children of service entries must not themselves be entries of type service. A client application can begin from the root entry and, by successively finding the children of an entry, can traverse the whole entry tree. The initial structure of the message entry tree is configured by specifying a list of entries. For information, see Message Store .
Interface for Messaging operations
Messaging Framework provides a tree view of a message consisting of the following component parts: subject, body, addressee list and attachments. The addressee list is referenced by list indices. Attachments are referenced by reference IDs generated by Messaging Framework.
Messaging Framework defines a standard set of messaging operations that can be performed on messages, such as create, save, reply and forward. The behaviour of most standard messaging operations is particular to the message type and is therefore provided by the plug-in modules. It also provides an interface that enables plug-in modules to support additional message type specific operations.
Interface for user-interface operations
Messaging Framework enables client applications to customise their user interfaces dynamically to access operations provided by plug-in modules for particular message types. For example, if a message client application has an email entry selected, it can obtain information on the menus and icons that it should display from the email plug-in module. It can also obtain information on user-interface operations that are suitable for use on the selected entry. For example, menu items that do not apply to particular entries could be greyed out.
The standard user-interface operations are: open, close, copy or move from, copy to, move to, create, delete, undelete, edit, view, forward and reply. In addition to the standard user-interface operations, each plug-in module may support a set of specific user-interface operations.
Utility functionality
Messaging Framework provides functionality to sort and search for text within rich or plain text. For more information, see Searching and Sorting Messages .
Messaging Framework is built upon the concepts of a message entry and a message.
A message entry is a unit of persistent storage in the framework. The framework stores all user messaging data in a tree structure of message entries. Each message entry has a type and there are five pre-defined types: root, message, service, folder and attachment. The set of entry types is extensible. The concept of a message entry is used by the plug-in modules to store their messaging data and may be used by client applications to access messaging data.
A message is mainly used by the messaging clients. By using this concept, the messaging clients can perform messaging operations without having to know which plug-in module is involved in the actual execution of the operations. For example, when using an email protocol a message refers to an email message and the messaging operations are executed by an email plug-in. The structure of a message is specific to a plug-in. A message may be stored as several message entries, or it may be stored as a single message entry.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.