[Syncevolution-issues] [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2010-03-08 09:16:06 PST ---
(In reply to comment #4)
(In reply to comment #1)
> (In reply to comment #0)
> There are two TODOs left:
>
> // TODO: create a suitable configuration automatically?!
>
> 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.
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.
> // TODO: use the session ID set by the server if non-null
>
> Testing of this feature depends on the deciding about the required server
> support.
In SyncEvolution, the session ID in SAN currently is fixed as "1", because
this
part of code is not accessed from syncevo-dbus-server which manages the session
ID. From a command line point of view, the session ID is meaning less and "1"
is OK.
We can support this via querying the session management from dbus server, but
does it has any benefits? (I don't see in SyncEvolution case)
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.
--
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.