3.1.4.3 Syncing Per-User Read/Unread Data for Public Folders

When the user marks an item as read/unread, switches to a different public folder, or logs off from the message store, the client synchronizes the per-user read/unread data for the public folder. Other high-level events, as determined by the implementer, can trigger a synchronization.

Public folder data is replicated across multiple servers, with each server maintaining per-user read/unread data for each public folder. The read/unread information is valid for that server only. If a subsequent logon results in the client being redirected to a different replica server, it is the client's responsibility to synchronize the current read/unread data to the new server.

For each public folder, the client issues a RopReadPerUserInformation (section 2.2.1.12) against the public message store (this is not necessary if the public folder has not been modified) to retrieve the per-user read/unread data. This data is then stored in the private message store by using RopWritePerUserInformation (section 2.2.1.13).

When a public folder is subsequently reopened in a later logon session, the client MUST check to see if the replica server has changed. This is done by issuing a RopGetPerUserGuid (section 2.2.1.11) against the private message store and comparing the REPLGUID returned (in the DatabaseGuid field) to the public message store REPLGUID, which is returned by RopLogon (in the ReplGuid field of the public folders logon response) (section 2.2.1.1). If the REPLGUIDs match (or RopGetPerUserGuid doesn't find the REPLGUID), then the public folder is in sync. If the REPLGUIDs don't match, the client MUST synch the read/unread data from the private message store up to the public message store. This is done in the reverse manner as the previous sync: the data is retrieved from the private message store by using RopReadPerUserInformation and sent to the public message store using RopWritePerUserInformation.

When synching using RopReadPerUserInformation and RopWritePerUserInformation, it is important to note that the size of the return data potentially exceeds the maximum amount of data that can be communicated in a single ROP. For this reason, the operation is designed to stream the data to the client by having the client invoke these ROPs multiple times. For details, see section 3.1.5.2.