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
_______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
