Symbian3/SDK/Source/GUID-54AB166A-8B24-5065-92AD-5FC1BF3ED89C.dita
changeset 0 89d6a7a84779
equal deleted inserted replaced
-1:000000000000 0:89d6a7a84779
       
     1 <?xml version="1.0" encoding="utf-8"?>
       
     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
       
     3 <!-- This component and the accompanying materials are made available under the terms of the License 
       
     4 "Eclipse Public License v1.0" which accompanies this distribution, 
       
     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
       
     6 <!-- Initial Contributors:
       
     7     Nokia Corporation - initial contribution.
       
     8 Contributors: 
       
     9 -->
       
    10 <!DOCTYPE concept
       
    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
       
    12 <concept id="GUID-54AB166A-8B24-5065-92AD-5FC1BF3ED89C" xml:lang="en"><title>Messaging
       
    13 Framework Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    14 <p>This section provides an overview of the functionality and the architecture
       
    15 of the Messaging Framework collection. </p>
       
    16 <section><title>Purpose</title> <p>Messaging Framework allows client applications
       
    17 to access the functionality of installed plug-in modules through a common
       
    18 interface. This allows client applications to be designed without foreknowledge
       
    19 of the message protocols that may later be used. </p> </section>
       
    20 <section><title>Architecture</title> <p>In ROM, Messaging Framework consists
       
    21 of the Message Server executable <filepath>msexe.exe</filepath> and two framework
       
    22 DLLs <filepath>msgs.dll</filepath>, <filepath>mtur.dll</filepath>. At run-time,
       
    23 messaging clients use APIs from the framework DLLs to access the framework’s
       
    24 functionality. </p> <p>Based on two main concepts explained above, Messaging
       
    25 Framework offers the following functionality: </p> <p><b>Functionality to
       
    26 manipulate the set of plug-in modules</b> </p> <p>The Message Type Module
       
    27 (MTM) architecture allows plug-ins to add support for new message types. All
       
    28 interactions with lower-level communication protocols, for example TCP/IP
       
    29 or SMS stack, are performed by the plug-in modules. The set of installed plug-in
       
    30 modules can be changed by installing a new plug-in or removing an installed
       
    31 plug-in. Plug-in modules are identified by their name. Messaging Framework
       
    32 requires a new plug-in module to provide registration data such as its name,
       
    33 version number and function entry points. For an example of a plug-in registration
       
    34 file, see <xref href="GUID-E96D8052-0CB2-53A6-915F-133D3058DCF9.dita">MTM resource
       
    35 file</xref>. </p> <p><b>Functionality to store message entries</b> </p> <p>Messaging
       
    36 Framework provides the functionality to store message entries, index data,
       
    37 a set of streams and binary files. For information, see <xref href="GUID-D099551B-6E99-5210-B44A-693012A29DD1.dita">Types
       
    38 of Storage for a Message Entry</xref>. </p> <note>Entries always have index
       
    39 data, but they may have an empty set of streams or an empty set of associated
       
    40 files. For example, folder entries can be completely described by index data.</note> <p><b>Functionality
       
    41 to navigate the tree of message entries</b> </p> <p>Messaging Framework provides
       
    42 the tree view of message entries. The tree has a root entry. The children
       
    43 of the root entry must be entries of type service. The children of service
       
    44 entries must not themselves be entries of type service. A client application
       
    45 can begin from the root entry and, by successively finding the children of
       
    46 an entry, can traverse the whole entry tree. The initial structure of the
       
    47 message entry tree is configured by specifying a list of entries. For information,
       
    48 see <xref href="GUID-8390D842-B8A3-5042-952D-73240DB30D6B.dita#GUID-8390D842-B8A3-5042-952D-73240DB30D6B/GUID-8E01ADD0-A706-54B2-8159-E65C33274C30">Message
       
    49 Store</xref>. </p> <p><b>Interface for Messaging operations</b> </p> <p>Messaging
       
    50 Framework provides a tree view of a message consisting of the following component
       
    51 parts: subject, body, addressee list and attachments. The addressee list is
       
    52 referenced by list indices. Attachments are referenced by reference IDs generated
       
    53 by Messaging Framework. </p> <p>Messaging Framework defines a standard set
       
    54 of messaging operations that can be performed on messages, such as create,
       
    55 save, reply and forward. The behaviour of most standard messaging operations
       
    56 is particular to the message type and is therefore provided by the plug-in
       
    57 modules. It also provides an interface that enables plug-in modules to support
       
    58 additional message type specific operations. </p> <p><b>Interface for user-interface
       
    59 operations</b> </p> <p>Messaging Framework enables client applications to
       
    60 customise their user interfaces dynamically to access operations provided
       
    61 by plug-in modules for particular message types. For example, if a message
       
    62 client application has an email entry selected, it can obtain information
       
    63 on the menus and icons that it should display from the email plug-in module.
       
    64 It can also obtain information on user-interface operations that are suitable
       
    65 for use on the selected entry. For example, menu items that do not apply to
       
    66 particular entries could be greyed out. </p> <p>The standard user-interface
       
    67 operations are: open, close, copy or move from, copy to, move to, create,
       
    68 delete, undelete, edit, view, forward and reply. In addition to the standard
       
    69 user-interface operations, each plug-in module may support a set of specific
       
    70 user-interface operations. </p> <p><b>Utility functionality</b> </p> <p>Messaging
       
    71 Framework provides functionality to sort and search for text within rich or
       
    72 plain text. For more information, see <xref href="GUID-32C1FC8B-F7D2-5275-BDF2-0D662551294C.dita">Searching
       
    73 and Sorting Messages</xref>. </p> <p> </p> </section>
       
    74 <section><title>Description</title> <p>Messaging Framework is built upon the
       
    75 concepts of a message entry and a message. </p> <p>A <b>message entry</b> is
       
    76 a unit of persistent storage in the framework. The framework stores all user
       
    77 messaging data in a tree structure of message entries. Each message entry
       
    78 has a type and there are five pre-defined types: root, message, service, folder
       
    79 and attachment. The set of entry types is extensible. The concept of a message
       
    80 entry is used by the plug-in modules to store their messaging data and may
       
    81 be used by client applications to access messaging data. </p> <p>A <b>message</b> is
       
    82 mainly used by the messaging clients. By using this concept, the messaging
       
    83 clients can perform messaging operations without having to know which plug-in
       
    84 module is involved in the actual execution of the operations. For example,
       
    85 when using an email protocol a message refers to an email message and the
       
    86 messaging operations are executed by an email plug-in. The structure of a
       
    87 message is specific to a plug-in. A message may be stored as several message
       
    88 entries, or it may be stored as a single message entry. </p> </section>
       
    89 <section><title>Components</title> <p>The Messaging Framework collection comprises
       
    90 the following components: </p> <ul>
       
    91 <li id="GUID-931DA131-2DA8-5514-9312-15730C1F390C"><p><xref href="GUID-B394A824-8745-505E-8429-8B9B6D418387.dita">Message
       
    92 Server and Store</xref>  </p> </li>
       
    93 <li id="GUID-C7700C69-CB15-5177-8EE1-14C27114DFCC"><p><xref href="GUID-E7BB0B0F-FC27-5428-81C0-1AB9CA426571.dita">BIO
       
    94 Messaging Framework</xref>  </p> </li>
       
    95 <li id="GUID-B139D5EB-1F7F-5950-8F97-77F2E4C69DA4"><p><xref href="GUID-CADAABB4-C957-502E-BA4D-E9614C0D3878.dita"> Scheduled
       
    96 Send MTM </xref>  </p> </li>
       
    97 <li id="GUID-170867DF-E65A-5779-AA2F-488151931CDE"><p><xref href="GUID-63816E09-46C7-503A-ADA0-E350C7ACF3C4.dita"> SendAs </xref>  </p> </li>
       
    98 <li id="GUID-F53CBD73-6AE8-576A-A202-B57AFF08D626"><p><xref href="GUID-4603D4ED-966F-5F70-B991-D10495BC2D7E.dita">Watcher
       
    99 Framework</xref>  </p> </li>
       
   100 <li id="GUID-1C38FEB0-0ECF-5917-9C32-9153D91D8540"><p> <xref href="GUID-5900DB92-8D4D-5487-8EFE-AB9CEB8BA93B.dita">WAP
       
   101 Push Framework</xref> </p> </li>
       
   102 </ul> </section>
       
   103 </conbody><related-links>
       
   104 <link href="GUID-44CF5471-564E-5790-935B-51193A4978D6.dita"><linktext>Message Server
       
   105 and Store Concepts</linktext></link>
       
   106 </related-links></concept>