Share via

3.3.5.8.13 Sending a RopSetLocalReplicaMidsetDeleted ROP Request

  • Article

The client MUST ensure that ranges supplied as request fields to the RopSetLocalReplicaMidsetDeleted ROP (section 2.2.3.2.4.8) are allocated by using the RopGetLocalReplicaIds ROP (section 2.2.3.2.4.7).

The value of the LongTermIdRanges field MUST only identify IDs that were assigned to an item on the client but never uploaded to the server, as well as IDs that the client will never use in the future. The value of the LongTermIdRanges field MUST NOT identify IDs that exist on the server; failure to comply with this requirement results in an inconsistent state between the client and server as the server adds the ID to the deleted items list and the item will be deleted from the client during the next synchronization while the item will still exist on the server.

The following example shows a possible implementation of the client with regards to assignment of server-allocated IDs, as specified in section 3.3.5.2.1, to objects in a local replica. Clients do not have to follow the example specified in this section; it is only used to show the applicability of the RopSetLocalReplicaMidsetDeleted ROP (section 2.2.3.2.4.8):

  1. Initially, a client has no server-allocated IDs that it can assign to objects that are created when working offline, so it is required to ask the server to allocate a block of IDs by sending the RopGetLocalReplicaIds ROP (section 2.2.3.2.4.7). The server responds with a block of IDs that the client stores in a local replica.

  2. The client requires the server-allocated ID whenever it has to create a message in a folder in a local replica. For that purpose, the client associates a range of IDs previously allocated with the RopGetLocalReplicaIds ROP with a folder, so that IDs from that range can be used for new or moved items in that folder.

  3. The client creates a message in the local replica and assigns it a server-allocated ID from the set of IDs previously allocated to the folder from a call to the RopGetLocalReplicaIds ROP in step 2.

  4. The client then deletes the message from the local replica before the message is uploaded to the server, because, for example, the client is offline.

  5. The client issues the RopSetLocalReplicaMidsetDeleted ROP for the ID that was consumed by the client, but never passed to the server.