Syncml Features

reference:http://developers.sun.com/mobility/midp/articles/syncml/ Features and requirements defined by the SyncML synchronization protocol include: Change logs: Both the client and the server are required to maintain information about changes to the data in their databases. The SyncML specification doesn't specify the format of the change log, but each device must be able to specify the data items that have changed since the previous synchronization. Sync anchors: A sync anchor is a string representing a synchronization event. There are two, Last and Next, sent in the initialization stage of the synchronization process. The Last sync anchor describes the last event when the database was synchronized, and the Next sync anchor describes the current sync event, both from the sending device's point of view. The receiving device must store each Next sync anchor it receives until the next synchronization. At that time, the receiving device compares these stored Next sync anchors with the sending device's Last sync anchor. If the Lastand Next sync anchors match, the receiving device concludes that no failures have occurred since the last sync; if they don't match, the device can request a special action from another device, such as a slow sync, in which all items in the client databases are compared w. Mapping of data items: The client and the server may each have their own unique identifier for each data item in their databases. The client ID for an item is known as the Locally Unique ID (LUID), and the server ID is known as the Globally Unique ID (GUID). Because these IDs can differ, the server must maintain an ID mapping table. For example, for an item called "Car" the client's LUID may be 45, while the server's GUID may be 101451. The server's two-column ID mapping table would show that LUID = 45 is mapped to GUID = 101451. Note that LUIDs are always assigned by the client; if the server sends a new item to the client, the client assigns it an LUID and sends that local ID back to the server for mapping to a GUID. Conflict resolution: Conflicts arise when changes to the same item occur on both the client and server databases. These are generally resolved by a sync engine on the server device. The protocol provides the functionality to notify the client of a resolved conflict, supplying one of the status codes for common resolution policies. Therefore, if the sync engine on the server resolves a conflict, it can send information about the conflict and how it was resolved