SyncML: A technical perspective (Re: New kolab version ?)

[Gunnar Wrobel]

Quoting Del <delonly at gmail.com>:

> On Sat, 2008-11-08 at 13:44 +0100, Gunnar Wrobel wrote:
>> A year ago I would have agreed with you. That was *before* I
>> implemented SyncML support for Kolab. SyncML has some severe problems.
>> Maybe not so much in the area of the protocol. But the fact that the
>> actual data exchange elements used within the protocol are being left
>> undefined means that any real world implementation will only ever work
>> with some devices. Not with all. There will always be a plethora of
>> device specific incompatibilities.
>
> Thanks for sharing your concerns and hindsight. I must admit that I
> haven't looked into the SyncML protocol, so I am not familiar with its
> shortcomings. I am grateful for any negative experiences you can share,
> e.g., handsets that work well or not.

In general each mobile family needs its own driver in the SyncML  
implementation. This driver will handle data conversion so that both  
server and client can understand each other. As mentioned SyncML  
itself is only a protocol wrapper and does not care about the data  
carrier it is used with.

Usually the data carrier are vCards or iCal objects. But both vCard  
and iCal have not been designed for synchronization. They are simple  
storage formats. If they are being used as synchronization messages  
you get some interesting side effects. As an example: If the client  
sends a vCard without an email entry does that mean that the attribute  
should be left unchanged or did the user delete the attribute on the  
client? There are workarounds possible but there are even more complex  
problems when you get to multi-value attributes.

As such design problems are being interpreted differently by each  
client vendor you can imagine how well it works in the real world. You  
can basically tell your users: "It might work, it might not. Just try  
:)". Not good.

>
>> I deliberately describe this in a negative way. Of course things will
>> often work and make users happy. But from a technical point of view
>> I'm pretty convinced that SyncML is not really going anywhere. Or let
>> me rephrase: I hope it is not going anywhere.
>
> I do see the need for an open standardised protocol, do you see any
> alternative? Is it feasible to extend SyncML specifications to mend the
> shortcomings?

vCard is currently trying to improve the format so that it can be used  
for synchronization. But that seems to be difficult.

Of course you can try to get better data formats for synchronization  
but I can guarantee you that standardization processes take a long time.

The other alternative is what I described: Use a storage format rather  
than synchronization. "Read/Write" is much easier to implement than  
"Read/Write Client - Synchronize Client/Server - Read/Write Server".

>
>> Kolab is doing one thing right: It defines a format that any client
>> should be able to read and write so that all other compliant clients
>> can also work with the stored data. This is a pretty robust approach
>> and syncing is not.
>
> Still, this requires everybody to adapt to Kolab's format, I do not
> think it is a good technical solution.

Huh? Why not? The format of the format (use of xml) maybe something  
open to discussion. But the general idea: using a simplified format  
that can be understood by each client is the right direction.

> Do you have any experience with
> Funambol's connectors? Seems they could potentially clear out some of
> the troubling points having connectors to most devices.

As far as I know their connectors are already quite good. But I don't  
have much experience with them.

>
>> If you want clean support for this on a mobile client it is actually
>> not too difficult: You add a Kolab Format compliant IMAP client on
>> your mobile device and you will be fine. No syncing, no problems.
>>
>> Will future clients support this? Yes, no question. IMAP access on a
>> mobile client is nothing fancy. And this is why I'm currently certain
>> that SyncML is just a temporary thing.
>
> A good point. However, is there any Kolab client underway that will run
> on most mobile devices? If not, what kind of time span are we in for?

It is just the most reasonable solution. There are no concrete  
schedules or anything. And as I mentioned initially I believe that  
SyncML will indeed be a temporary solution and people will use it. But  
in the long run I don't think it is a good solution.

Cheers,

Gunnar

>
> Cheers,
> Del
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/users/attachments/20081109/a0dcd5a5/attachment.sig>