Document name | syncml_intro.html |
---|---|
Author | MY |
Last updated | $Id: syncml_intro.html,v 1.7 2001/03/17 22:51:38 jaikonen Exp $ |
Reviewers | AS, TK |
Version | Date | Updater | Description |
---|---|---|---|
0.1 | 12.10.2000 | MY | Document created |
0.2 | 23.10.2000 | MY | Document cleaned |
0.3 | 17.3.2001 | JI | Minor updates |
Date | Reviewer | Comments |
---|---|---|
6.11.2000 | AS | Spell check and some modifications. |
A SyncML Client refers to the data synchronization role when an application issues SyncML "request" messages. For example, the Sync SyncML command in a SyncML Message. A device, which acts only in the SyncML client role does not include any synchronization engine capability.
This is the device that contains a synchronization client agent and it usually sends the SyncML messages (operations), possibly including payload data. It must also be able to receive responses from the SyncML server. In addition, it may be able in some cases to receive some SyncML messages as commands from the server side. Typically, this device is a PC, mobile phone, or PDA.
The act of establishing equivalence between two data collections. After data synchronization, each data element in one collection maps to a data element in the other, and their data is equivalent, though not necessarily identical.
This is the device, which contains a synchronization server agent and synchronization engine and which receives usually the SyncML messages (operations) possibly including payload data from the SyncML client. The SyncML server must also be able to send the responses to the commands if needed. In addition, it can be able in some cases to send some SyncML messages as commands to the client. Typically, this device is a networked server or a PC.
The well-defined specification for the "handshaking" or workflow required accomplishing synchronization of data elements in an originator and a recipient data collection. The SyncML specification forms the basis for specifying an open data synchronization protocol.
A SyncML Server refers to the data synchronization role when an application issues SyncML "response" messages. For example, a Results command in a SyncML message. The SyncML server is responsible for performing the analysis of the synchronization data so it must include a synchronization engine.
The portion of a SyncML server that can analyze a data set and modifications to that data set made by both SyncML server and SyncML client. The synchronization engine will implement policies to enable the detection and resolution of conflicting changes.
SyncML Components
1) An XML-based representation protocol
2) A synchronization protocol.
3) Transport bindings for the synchronization protocol
The SyncML representation and synchronization protocols are transport-independent.
The synchronization protocol supports both two-way and one-way synchronization.
The initial binding specified is e.g. HTTP.
Either the client or the server may initiate a synchronization session and both one and two-way synchronization is supported.
The messages are represented as XML documents.
A SyncML Message is a well-formed, but not necessarily valid, XML document.
The SyncML format also can be identified as a MIME content type.
Based on a request/response command structure or on a push command structure.
SyncML defines a number of "request" commands. Some of these commands act as containers for other commands.
Some commands are defined such that they may only be used either inside or outside of a Sync command.
SyncML "request" commands (only some of them)
1)
Delete
Allows the originator to ask that a data element or collection of data elements
accessible to the recipient be deleted. A delete command can include a request for the
archiving of the data. The deletion can either be a soft- or hard-delete.
2)
Get
Allows the originator to ask for a data element or collection of data elements from
the recipient. A get can include the resetting of any meta-information that the recipient
maintains about the data element or collection. This command must not be specified
within a Sync command.
3)
Put
Allows the original to put a data element or collection of data elements to the
recipient. This command must not be specified within a Sync command.
4)
Update
Allows the originator to ask that a data element or collection of data elements
accessible to the recipient be updated. An update can mean complete replacement of
the data element. This command must only be specified within a Sync command.
SyncML "response" commands.
1)
Status
Indicates the completion status of an operation or that an error occurred while
processing a previous request.
2)
Results
Used to return the data results of either a Get or Search SyncML
Command.
The SyncML specification does not define how a synchronization engine performs synchronization, or how to configure the client and server to talk to each other. These are considered as areas, which are premature or inappropriate to standardize.
SyncML does not require two data collections to be homogeneous in order to synchronize with each other.
For example, a document on the data synchronization server could be identified with a globally unique identifier or GUID.
The server is responsible for maintaining the list of GUID/LUID tuples.