--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-54AB166A-8B24-5065-92AD-5FC1BF3ED89C.dita Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,106 @@
+<?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>
\ No newline at end of file