Platform SDK: MAPI

Remote Transport Architecture

Your remote transport needs to translate user requests for message data into intelligently managed connections to the messaging server without requiring the user to manage the individual connections. This is accomplished through the MAPI remote architecture as shown in the following illustration.

Client applications which are remote-enabled (remote viewers) communicate with the MAPI spooler and remote transport providers as usual for nonremote tasks such as logging on or flushing queues. In addition, the client application uses the remote transport's IMAPIFolder interface to perform remote tasks such as downloading message headers.

The remote viewer is a client application designed to work with remote transport providers. Remote viewer applications can check the MAPI status table for remote transport providers, those that have set the STATUS_REMOTE_ACCESS bit in their status table row, and adjust their user interface appropriately. Remote viewers are expected to utilize a special folder that contains header information about messages in the user's Inbox. The header information is stored locally and can be used to selectively mark messages for download or deletion.

A remote transport provider is similar to a message store because it implements the IMAPIFolder interface; however, the folder so implemented is not identical to the generalized hierarchical folders that message stores implement. For a remote transport provider, the folder is an intermediary between the client application and the remotely accessed message store. The message headers and message identifiers in the folder do not necessarily correspond to messages that are stored locally on the user's computer or stored in any immediately accessible way.

The folder is expected not to have subfolders, although the presence of subfolders should not cause client application problems since they should not be displayed. Opening the folder does not cause the folder's contents to be downloaded. At the user's request, message headers can be downloaded and looked at off-line or at a later time. Remote transport providers should provide some sort of local cache or storage facility for downloaded message headers so that the folder can be populated with cached message headers when it is opened without connecting to the remote message store.