|
From: Michael B. <mic...@cm...> - 2010-12-14 14:58:21
|
Hi Patrick,
On 12/13/10 08:50, Patrick Ohly wrote:
>
> On So, 2010-12-12 at 21:03 +0100, Michael Bell wrote:
>> SyncML merging will always be a problem. If a device is out of sync and
>> there are changed items on both sides there is always the risk of
>> duplicated entries. I can just note here that this behaviour is just
>> unacceptable for customers with many contacts and events. This leads to
>> our (university's) decision for Active Sync.
>
> I agree that merging in a slow sync is difficult, and that involving
> unrelated devices just makes it harder. I have not looked at Active Sync
> in detail yet. Does it prescribe that all items must have a unique ID?
>
> What if someone has data in his phone and starts syncing with a server
> which also has data ("first time slow sync" in SyncML)? Does Active Sync
> require that one side is wiped clean before syncing can start? Otherwise
> I don't see how this use case can be supported without merging.
We have a very well defined workflow ;) First we have an empty mobile.
Second we synchronize it for the first time with our calendar server.
After this point all events have a GUID. So if a synchronization fails
(perhaps because of an UMTS problem) then even a "slow" sync in active
sync cannot create tons of duplicates. If you don't make changes on the
phone then you will have no problems with SyncML too but the most users
does not have this discipline ;)
> It's getting more off-topic, but can you say also a bit about what
> implementations of Active Sync the Humboldt university will support
> (client and server side)? This being a university, I would hope that
> such information can be shared (perhaps off-list).
Actually we just defined the client side which must be supported and we
begin to evaluate the server market. We don't make big statements to the
public even the university's employees. So I can give you some
informations but only on a "NDA" base like with libsynthesis in the past.
If there is a final decision then the decision will be public. Today we
use Oracle OCS with SyncML and clients from Synthesis.
Best regards
Michael
--
___________________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
mic...@cm... D-10099 Berlin
___________________________________________________________________
PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB
|