Messaging -Framework Overview

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 + + + + + +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