4.2 Synchronization Digest

The digest payload is a compact XML structure that describes the synchronization state of a resource collection at a given synchronization endpoint.

For example, the digest associated with http://www.example.com/sdata/myApp1/myContract/-/accounts/$syncDigest could be:

<digest xmlns="http://schemas.sage.com/sdata/sync/2008/1">
  <origin>http://www.example.com/sdata/myApp1/myContract/-/accounts</origin>
  <digestEntry>
    <endpoint>http://www.example.com/sdata/myApp1/myContract/-/accounts</endpoint>
    <tick>5</tick>
    <stamp>2008-10-30T14:52:03.281Z</stamp>
    <conflictPriority>2</conflictPriority>
  </digestEntry>
  <digestEntry>
    <endpoint>http://www.example.com/sdata/myApp2/myContract/-/accounts</endpoint>
    <tick>11</tick>
    <stamp>2008-10-30T13:46:45Z</stamp>
    <conflictPriority>1</conflictPriority>
  </digestEntry>
  <digestEntry>
    <endpoint>http://www.example.com/sdata/sageApp3/test/-/accounts</endpoint>
    <tick>8</tick>
    <stamp>2008-10-30T12:40:25Z</stamp>
    <conflictPriority>3</conflictPriority>
  </digestEntry>
</digest>

This digest indicates how the digest’s endpoint is synchronized with respect to other endpoints. It contains a collection of <digestEntry> elements. In the example above, the digest indicates that the sageApp1 accounts endpoint (digest’s URL) is in synch with sageApp1’s acounts endpoint (with itself) at tick 5, with sageApp2’s accounts endpoint at tick 11 and with sageApp3’s accounts endpoint at tick 8.

The digest also gives the conflict priorities of the various endpoints. This information will be used to resolve conflicts (see Conflict Handling section).

The SData protocol supports arbitrary topologies. These is no limit to the number of endpoints present in a digest..

The <digest> element contains the following XML artefacts:

XML Element	Example Value	Description
origin	http://www.example.com/sdata/myApp1/myContract/-/accounts	The endpoint from which the digest was obtained.
digestEntry	(see example above)	Describe how the endpoint is synchronized with respect to other endpoints.

The following table describes the structure of a <digestEntry> element:

Element	Type	Example Value	Description
endpoint	URL	http://example.com/sdata/myApp2/myContract/-/accounts	Identifies the remote endpoint, sageApp2's accounts endpoint in this example.
tick	integer	11	Tick that describes how the local endpoint is synchronized with the remote endpoint. In this example, sageApp1's accounts endpoint is synchronized with sageApp2's accounts at tick 11. This means that sageApp1 has incorporated all the changes applied to accounts on sageApp2 until sageApp2's tick reached 11.
stamp	datetime	2008-10-30T13:46:45Z	Timestamp at which the digest entry's tick has been last modified. This timestamp is used by the algorithm that propagates UUID changes to decide whether it needs to send old UUIDs or not.
conflictPriority	integer	1	Conflict priority for the endpoint. In the example above, if a conflict is detected between a change made on sageApp2 and sageApp1, sageApp2 will win because its priority (1) is lower than sageApp1's priority (2).

Conflict priority values are arbitrary integers in the [1, 9] range. A value of 1 indicates a very strong desire to win conflicts. A value of 9 indicates a very weak desire to win them. All the intermediate values are allowed and can be used to fine tune the conflict resolution strategy when more than two nodes are involved.

If both sides have the same priority, the “last one who writes wins” rule will apply to resolve the tie.

The payload for the operations supported on the $syncDigest URL MUST conform to the format described in this section and MUST contain a digestEntry for every endpoint recorded within the provider. Additionally, the pair (endpoint, tick) MUST be the highest known for the pair within the application.

---