[Owncloud] Why SyncML (was Re: GSoC Sync Client - Server Component)

Cédric Venet cedric.venet at laposte.net
Wed Jun 22 08:32:54 UTC 2011


>  IMHO Riccardo has a good point. At the cost of java dependency we
>  could bring the whole SyncML infrastructure in right now. This might
>  be as an optional app that can be disabled if the target system
>  lacks support, so the integrity of remaining features is not
>  compromised.

One question which has not been answered is what are the advantages of 
SyncML versus other protocol?
It was only said that this was a standard with lot of existing 
clients... from the wikipedia page (i know this is not a reference), i get:
  * A fairly intricate and vague protocol specification has meant that 
in general there are major interworking problems with different servers 
against different clients
  * SyncML requires a /database name/ to be specified for opening a 
connection. This database name is not standardized, and different 
servers use different names for the same service
  * According to the documentation in the Funambol SyncML wiki, there is 
no conflict resolution. The server can only be set to 'client wins' or 
'server wins' in case a field has been edited both on server and on client.

This does not seems very interesting. A complex and incomplete standard 
is worst than a simple well defined one. Especially if there is no good 
php implementation (and KDE does not support SynML?). But maybe this is 
wrong (since it is from wikipedia). So why push so much in favor of syncml?

regards,
Cédric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20110622/ca063972/attachment.html>


More information about the Owncloud mailing list