<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-54AB166A-8B24-5065-92AD-5FC1BF3ED89C" xml:lang="en"><title>Messaging

Framework Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>This section provides an overview of the functionality and the architecture

of the Messaging Framework collection. </p>

<section><title>Purpose</title> <p>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. </p> </section>

<section><title>Architecture</title> <p>In ROM, Messaging Framework consists

of the Message Server executable <filepath>msexe.exe</filepath> and two framework

DLLs <filepath>msgs.dll</filepath>, <filepath>mtur.dll</filepath>. At run-time,

messaging clients use APIs from the framework DLLs to access the framework’s

functionality. </p> <p>Based on two main concepts explained above, Messaging

Framework offers the following functionality: </p> <p><b>Functionality to

manipulate the set of plug-in modules</b> </p> <p>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 <xref href="GUID-E96D8052-0CB2-53A6-915F-133D3058DCF9.dita">MTM resource

file</xref>. </p> <p><b>Functionality to store message entries</b> </p> <p>Messaging

Framework provides the functionality to store message entries, index data,

a set of streams and binary files. For information, see <xref href="GUID-D099551B-6E99-5210-B44A-693012A29DD1.dita">Types

of Storage for a Message Entry</xref>. </p> <note>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.</note> <p><b>Functionality

to navigate the tree of message entries</b> </p> <p>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 <xref href="GUID-8390D842-B8A3-5042-952D-73240DB30D6B.dita#GUID-8390D842-B8A3-5042-952D-73240DB30D6B/GUID-8E01ADD0-A706-54B2-8159-E65C33274C30">Message

Store</xref>. </p> <p><b>Interface for Messaging operations</b> </p> <p>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. </p> <p>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. </p> <p><b>Interface for user-interface

operations</b> </p> <p>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. </p> <p>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. </p> <p><b>Utility functionality</b> </p> <p>Messaging

Framework provides functionality to sort and search for text within rich or

plain text. For more information, see <xref href="GUID-32C1FC8B-F7D2-5275-BDF2-0D662551294C.dita">Searching

and Sorting Messages</xref>. </p> <p> </p> </section>

<section><title>Description</title> <p>Messaging Framework is built upon the

concepts of a message entry and a message. </p> <p>A <b>message entry</b> 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. </p> <p>A <b>message</b> 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. </p> </section>

<section><title>Components</title> <p>The Messaging Framework collection comprises

the following components: </p> <ul>

<li id="GUID-931DA131-2DA8-5514-9312-15730C1F390C"><p><xref href="GUID-B394A824-8745-505E-8429-8B9B6D418387.dita">Message

Server and Store</xref>  </p> </li>

<li id="GUID-C7700C69-CB15-5177-8EE1-14C27114DFCC"><p><xref href="GUID-E7BB0B0F-FC27-5428-81C0-1AB9CA426571.dita">BIO

Messaging Framework</xref>  </p> </li>

<li id="GUID-B139D5EB-1F7F-5950-8F97-77F2E4C69DA4"><p><xref href="GUID-CADAABB4-C957-502E-BA4D-E9614C0D3878.dita"> Scheduled

Send MTM </xref>  </p> </li>

<li id="GUID-170867DF-E65A-5779-AA2F-488151931CDE"><p><xref href="GUID-63816E09-46C7-503A-ADA0-E350C7ACF3C4.dita"> SendAs </xref>  </p> </li>

<li id="GUID-F53CBD73-6AE8-576A-A202-B57AFF08D626"><p><xref href="GUID-4603D4ED-966F-5F70-B991-D10495BC2D7E.dita">Watcher

Framework</xref>  </p> </li>

<li id="GUID-1C38FEB0-0ECF-5917-9C32-9153D91D8540"><p> <xref href="GUID-5900DB92-8D4D-5487-8EFE-AB9CEB8BA93B.dita">WAP

Push Framework</xref> </p> </li>

</ul> </section>

</conbody><related-links>

<link href="GUID-44CF5471-564E-5790-935B-51193A4978D6.dita"><linktext>Message Server

and Store Concepts</linktext></link>

</related-links></concept>