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 ...
What does a SyncML session looks like ?
To summarize :
- a client sends a "coucou" to the server
- the server asks for authentication data
- the client sends the login/password
- the server checks the login/password in eGW
- 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 :)