Message +Server and Store Overview

This section provides an overview of the functionality and the architecture +of Message Server and Store.

Purpose

The following services that are provided +by this component can be used by the client application:

Storing +Messages
Handling +Client Requests
Caching
Searching +and Sorting Messages

Architecture

Message type-dependent operations, +such as address handling, are called by client applications using client MTMs +and UI MTMs. These MTMs then access the appropriate Message Store and alter +it as required.

The following figure shows the logical structure of +the Message Server. Dashed boxes indicate components that can be developed +by third-parties.

+ Logical structure of Messaging Middleware architecture + + + No lower-level communication components are shown, as the architecture +is designed to be independent of any particular communication protocol. Instead, +communication libraries are accessed as needed by Server MTMs. For example, +an SMTP MTM would use TCP/IP, while the SMS MTM would use the Telephony Server +(ETel).

Application/App UI: This represents a message client application.
User Interface MTM, Client-side MTM, UI Data MTM, Server-side MTM Bases: These are base classes required for implementing protocol-specific +MTM components. User Interface and UI Data MTMs handle user interface functionality +and resources. Client-side MTMs provide message data handling functions. Server-side +MTMs provide message transport functions.
Concrete User Interface MTM, Concrete Client-side MTM, Concrete UI Data +MTM, Concrete Server-side MTM: These represent instances of MTM components written to implement a +particular messaging protocol.
Message Server: The Message Server handles all requests to access or manipulate message +data. Where necessary, it passes requests to the protocol-specific message +transport components, the Server-side MTMs.
Session: Sessions allow client-side components to issue requests to the Message +Server. There are a number of classes provided to clients that allow message +entries to be manipulated.

The msgs.dll library provides a client-side +session class called CMsvSession . Client applications +typically create an instance of this class on start-up. Instances of Client +MTMs, User Interface (UI) MTMs and high-level client library classes maintain +a reference to the client application’s session object, to make requests if +needed.

Message client applications, Client MTMs and UI MTMs manipulate +entries through TMsvEntry and CMsvEntry classes. +The entry currently being operated on is called the context. A client application +can begin by setting the context to the root entry. By finding the children +of this initial entry, and then their children in turn, any entry can be found.

Operations +such as creating, deleting, sorting and accessing body text, or changing an +index entry, which are independent of the message-type, are requested by client +applications and MTMs through CMvsEntry or CMsvServerEntry. +The Message Server may either perform such operations itself or delegate them +to a server MTM.

Description

The Message Server is the core component +in the Messaging Middleware module. It accepts asynchronous requests from +clients through a kernel-maintained session. It performs the following functions:

Controls access +to message data

In response to client requests, the Message Server +delegates temporary, exclusive access to message data, so that more than one +client cannot edit the same message at the same time. It is the responsibility +of Message Server to keep the message data in workable order, and cope with +events such as failure recovery.
Delegates requests +to Server MTMs

Message Server must identify requests, such as +sending a message that requires protocol-specific functionality, and load +the appropriate Server MTM.

Message Store

Message +Server provides persistent storage of messages and messaging account settings +by providing a Message Store. The Message Store contains message data in a +variable number of entries in a tree view, each of which is referenced by +a unique identifier. This concept is known as a dictionary +file store. Each entry in the tree can represent an email account, +folder of messages, message part and so on.

Message Store is secured +in a protected data-caged area of Message Server. Message Server allows multiple +read-only and a single read-write access to a message in the Message Store +at given time. It also accepts copy and delete requests from clients trusted +with WriteUserData capability. When a copy or delete is requested, +the message server first flags itself as unavailable and then locks the files +before attempting to process them.

Message settings are stored in +the Central Repository and attachment information is stored in the Message +Store. MTMs can create additional streams in the message store to hold MTM-specific +message data. Usually, at least one stream is devoted to non-generic header +information such as recipient information.

When Message Server starts, +the Message Store is created unless there is already a Message Store present. +Message Server initially creates the Message Store with just a root entry +and then creates standard folders defined in the msgs.rsc resource +file. Finally the Message Server runs mailinit.exe to +customise of the Message Store. The behaviour of mailinit.exe is +defined by the UI family of the device, such as Series 60 or UIQ. However, +the typical behaviour is to load each of the UI MTMs and allow each to perform +any message type specific initialisation. For example, the SMS plug-in typically +creates a default service entry.

API summary

The storage abstractions through which +client applications access the various types of storage are key to the Messaging +Middleware module.

The CMsvEntry API +access and acts on a particular Message Server entry. The main functions of +this API are to provide means to:
- access the various types +of storage associated with an entry
- discover and access +other entries that the entry owns (its children)
CMsvServerEntry is +similar to CMsvEntry, but used only by Server MTMs.
TMsvEntry encapsulates +an index entry the Message Server index.
CMsvStore encapsulates +an entry’s Message +Store.
MMsvAttachmentManager class +is a pure virtual interface class that defines the APIs to be used for attachment +management in the Messaging Framework.

Typical uses

Configuring the Message +Server ans Store
Writing MTMs
Searching and sorting +messages
Processing emails in +chunks