Q: Could you please give an example of a very simple and basic SyncML
HTTP transaction (HTTP methods, headers, body)?
A: A SyncML Transaktion, tunneled via HTTP always uses a POST to the same URL:
Pkg #1: A client sends a post message to a specific url ( wwww.opengroupware.org/SyncML )
The SyncML package (in XML format) is completely in the post request. It includes what kind of sync (one-way, two-way) and maybe credentials. This also incluses extra info like last-sync-date
Pkg #2: The server responds with a SyncML package, either telling the client which sync-type to use or that it is unauthorized
The connection SHOULD be keep-alived, but it must work without that!
Pkg #1b, 2b: The client does another post, to the same URL. Usually this includes the same request but with credentials, the server responses.
Pkg #3: The client posts the requested change events, like add, delete, ...
Pkg #4: The processes the request, resolves conflicts, and posts a status and its change requests back to the client
The client now processes the request. In this case of events, it could assing new UIDs to objects (since the UID space of client and server may not match), therefore
Pkg #5: The Client sends it status and maybe a mapping table to the server
Pkg #6: The server responds with a status package
The End.
The Client must keep a last-sync-info: A last Sync Timestamp and some kind of changelog (can be reconstructed in most cases)
The Server must keep permanentely:
The same last sync info for EVERY client
Client info, like which data formats the client supports (is also exchanged within the SyncML session)
A UID mapping table
A SyncML package looks somehow like this (for more information, please see the specs, this is VERY much shortened)
<SyncML>
<SyncHdr>
<VerDTD>1.1</VerDTD>
<VerProto>SyncML/1.1</VerProto>
<SessionID>1</SessionID>
<Cred>...</Cred>
</SyncHdr>
<SyncBody>
<Status>...</Status>
<Sync>
<Target>...</Target>
<Source>...</Source>
<Add>...</Add>
<Replace>...</Replace>
</Sync>
</SyncBody>
</SyncML>
