Creating and Storing Messages in Message Stores

How your message store provider creates and stores messages in the underlying storage mechanism depends heavily on the underlying storage mechanism itself. In general, you need only to write code to preserve the properties of a message and their values.

When creating a new message, the message store provider needs to create it with the required properties for messages. A list of these properties can be found in the documentation for IMAPIFolder : IMAPIContainer. After that, client applications add any additional properties with IMAPIProp methods.

When saving a message to the underlying storage mechanism, the message store provider needs to iterate over the message's properties, and save them to the underlying storage mechanism such that they can be fully recovered if the message is later opened.

MAPI requires that the properties on IMessage objects are transacted, meaning that changes made to them do not become permanent until the IMAPIProp::SaveChanges method is called on the message object. The message store provider is responsible for implementing this behavior. Usually this is not difficult; it simply means holding properties in memory while they are being modified and committing them to the underlying storage mechanism when SaveChanges is called.

Some properties on message objects have special semantics for client applications with respect to the SaveChanges method:

• Some properties should be read/write before SaveChanges is called, but read-only afterwards. For example, PR_MESSAGE_FLAGS is set initially by the client application that creates the message (and thus is read/write) but can't be changed after the first call to SaveChanges.
• Some properties have special relations to properties on the folder they are in or to IMAPIFolder methods. For example, the PR_MESSAGE_FLAGS property is related to the flags used on the IMAPIFolder::CreateMessage call.
• Some properties may not be available until SaveChanges is called for the first time. For example, the PR_ENTRYID property may not be available until SaveChanges is called.
• Some properties can have special relationships to other properties on the message object. For example, the PR_BODY property is usually derived from the PR_RTF_COMPRESSED property in message store providers that support Rich Text Format messages.
• Some properties are used by more than one object type related to message stores. For example, the PR_STORE_SUPPORT_MASK property is required on folder and message objects as well as message store objects.

It is the responsibility of the message store provider to implement the correct semantics for such properties.