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