[Syncevolution-issues] [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #6 from Chen Congwu <congwu.chen(a)intel.com> 2010-03-10 23:43:17 PST
---
(In reply to comment #5)
> > We need to decide what the use cases for this are and which
kind of servers we
> > want to support. Nokia PC Suite? iSync? Our own SyncEvolution?!
> Let's support SyncEvolution first.
We need to define what that means. Does it mean that we expect the SyncML
server contacting us to use the addressbook/calendar/todo/memo URIs, without
looking at the SAN data formats? A new configuration then would be based on the
"SyncEvolution" server template with "syncURL" set to fit the peer.
Yes, that's what I meant.
That's a useful first step. The next step would be to identify
several other,
well-known URI names ("contacts", ...) and/or datatypes and map them to our
data sources.
That would better be done when we have scenarios/tests with other
external
servers.
I don't know what the effect of not using the suggested session ID is. I marked
it as a TODO because I saw that the SAN message contains it. Some servers might
depend on it.
Checking the spec, I don't think session ID was meant to be used
like this. The
ID is actually used to help the client to identify the same SAN requests from a
server (As the server might sent multiple SAN continuously) and thus only need
to respond to one of the requests.
Again this is not true for SyncEvolution Server at this moment, on the server
side we might first ensure the generated session ID need to be unique.
On the clietn side, I think we can implement like this:
If the SAN request with the same session ID was received within a reasonable
time period (say 1 hour), we should ignore this packet.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.