diff -r 89d6a7a84779 -r 25a17d01db0c Symbian3/PDK/Source/GUID-54AB166A-8B24-5065-92AD-5FC1BF3ED89C.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/PDK/Source/GUID-54AB166A-8B24-5065-92AD-5FC1BF3ED89C.dita Fri Jan 22 18:26:19 2010 +0000 @@ -0,0 +1,106 @@ + + + + + +Messaging +Framework Overview +

This section provides an overview of the functionality and the architecture +of the Messaging Framework collection.

+
Purpose

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.

+
Architecture

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.

Entries always have index +data, but they may have an empty set of streams or an empty set of associated +files. For example, folder entries can be completely described by index data.

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.

+
Description

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.

+
Components

The Messaging Framework collection comprises +the following components:

    +
  • Message +Server and Store

  • +
  • BIO +Messaging Framework

  • +
  • Scheduled +Send MTM

  • +
  • SendAs

  • +
  • Watcher +Framework

  • +
  • WAP +Push Framework

  • +
+
+Message Server +and Store Concepts +
\ No newline at end of file