Let's begin with a little description of how SyncML works.
SyncML is a xml language which describes how two "data-containers" can sync.
The two "data-containers" involved in a SyncML exchange are described as a client and a server :
the server is the one that resolves data conflicts
not the the client :)
In our case eGW is a server and palm is a client, for example, but a SyncML server could be written for palm and the SyncML server of eGW could act as a client syncing with another SyncML server, if it is well written. That is interesting if we want servers sync ...
if the login/password is wrong, the server sends a "no auth" to the client
if the login/password is right, the server sends a "ok, let's sync slow/normal" to the client
the client is registered?
if the server sees that it knows the client, it asks for anchors to the client (last time a sync was done)
if the server does not know the client, it asks for a slow sync and goes to 8
see note below on this and previous step
the client sends anchors to the server
the server checks the anchors and
if it matches its own anchors for the client, the server asks for a normal sync
if it does not match, the server asks for a slow sync
Sync starts
if it is a slow sync, the client sends all its datas
if it is a normal sync, the client sends all its datas added/changed/deleted since last sync, saying if it was added/etc ...
the server checks each record sent by the client for conflicts with what has been added/changed/deleted on its side since last sync, acknowlegdes added/changed/deleted datas and sends all datas that the client has to add/change/delete to him
the client acknowledges added/changed/deleted datas on its side and closes the session
Comments
Comments are welcome :)
This website is powered by eGroupWare's SiteMgr. The template was made by cwTech, NordicNet and irrsinn.de
This site uses google analytics