EPOC   SDK Home Glossary Indexes Previous Next Up

Message type modules


Contents


Overview

The Messaging Architecture provides base classes, which defines the component interfaces for MTM implementations. The base classes also provide implementations of some methods. The interfaces allows MTM components to be used polymorphically. As part of these interfaces, User Interface, Client-side, and User Interface Data MTMs must all support a function that allows message client applications to query the supported functionality: for example, the maximum message size, or whether attachments are supported.

MTM components must also be able to offer protocol-specific functionality not provided by base class interface functions. A MTM component defines UIDs that correspond to each protocol-specific capability offered, and implements a function that allow clients to access these capabilities by passing in the appropriate UID. Two versions of this function are available, supporting synchronous and asynchronous behaviour respectively.


User Interface MTMs

Users interact with different message types in different ways. For example, a messaging protocol that supports attachments needs a more feature-rich editor than one that only supports text. User Interface MTMs allow developers to produce user interface components to suit these differing requirements. Some messaging protocols may even not need any user interaction at all: in such cases, a User Interface MTM component does not need to be implemented.

User Interface MTMs offer some or all of the following capabilities:

A User Interface MTM need not supply all these functions. ER5’s Fax User Interface MTM, for example, does not supply folder manipulation, since folders are not appropriate within a fax service, but does provide pre-transfer preparation, as a fax may need to be rendered before transmitting.

Editors and viewers

Functionality to edit and/or view messages may be one of the larger programming tasks in creating an MTM. Such functionality is typically implemented in separate DLLs that the User Interface MTM loads as required, to reduce the memory footprint of a User Interface MTM.


Client-side MTMs

Client-side MTMs act as the interface between the internal representation of a message’s data and the User Interface MTM. This separation allows, for example, a User Interface MTM to offer a user interface to enter message addresses, without having to know the address storage format.

Client-side MTMs offer some or all of the following capabilities:

The entry with which the Client-side MTM is currently working is referred to as the context, similarly to CMsvEntry. User Interface MTMs always operate on the context set through the Client-side MTM.

Message client applications that do not require a user interface can use these functions directly for automated message handling.


UI Data MTMs

Message client applications are likely to need access to certain MTM-specific functions often and rapidly. These functions could be held in User Interface MTMs, but the resulting requirement to hold many User Interface MTMs in memory simultaneously could impose a large memory overhead. For this reason, a separate component type, the UI Data MTM, is defined.

UI Data MTMs offer the following capabilities:

The implementation of UI Data MTMs is relatively simple, as they contain little more than functions to return the required icons and extra menu items.


Server-side MTMs

The server-side component of an MTM deals with the interaction between the internal data representation of message data, and the transport components (for example, the sockets layer, or ETel). When receiving a message, a Server-side MTM creates a new index entry, and stores the message data in the entry and associated message store and binary files. Similarly, when sending a message, a Server-side MTM retrieves the message data, and translates the data into a format appropriate for the protocol.

Server-side MTMs should provide the following capabilities:

Some Server-side MTMs may also have the ability to create, delete, and change messages and folders on remote servers. Sophisticated Server-side MTMs may be able to cache requested operations off-line for execution at a later time.

Different Server-side MTMs interpret generic commands in different ways. For example, ER5’s Fax MTM transmits a fax when asked to copy a fax message from a local folder to a fax service. By contrast, an IMAP4 MTM could create a copy of the Internet mail message on the remote server and update the index to show the copy of the message on the remote server.

MTM-specific commands allow actions not defined by the base class interface to be made available. Some examples are: for fax, dial a fax back service; for IMAP4, perform a full synchronisation with a remote service; for POP3, connect to a remote server and download messages.


Registries

A record of all the MTM components installed on a machine is held in a dedicated file managed by the Message Server called the MTM Registry. Registry classes use this registration data to allow MTM components to be identified and instantiated. For example, the CClientMtmRegistry class has a member function to create a Client-side MTM object.

A similar process is used for User Interface and UI Data MTMs. Such MTM objects are owned by the clients that create them. Clients are also responsible for deleting these objects.

Server-side MTMs

Server-side MTM objects are created by a server-side registry class in response to calls from the Message Server. When the Message Server has no more requests queued for that MTM, it deletes the object. For efficiency, an MTM object can stop itself being deleted when more commands are expected shortly: see CommandExpected() — Prevent object deletion on command completion.

Component caching

Registry classes monitor the use of MTM component DLLs and maintain a reference count of the objects instantiated from each. This allows a registry class to unload a DLL when it is no longer required. However, message client applications can often require a particular MTM component a number of times in any particular session. The registry classes do not therefore immediately unload a component DLL when the reference count is zero. Instead, a timer is started. When the timer completes, the DLL is unloaded if its reference count has remained at zero for the duration.


Installation

An MTM can be installed on a target machine using the normal methods (e.g. .sis file). There are, however, two additional steps to take:

Uninstallation also requires a call to the Message Server. Running clients are then dynamically notified that the MTM is no longer available.

EPOC       SDK Home Glossary Indexes Previous Next Up