LWN: Comments on "SyncML: an introduction, its potential, its problems"

SyncML: an introduction, its potential, its problems

pohly — 2009-04-19T11:55:59+00:00

What you describe sounds like ActiveSync for locally connected devices. There's also ActiveSync for over-the-air synchronization. My (as I said, unfortunately very uniformed) impression is that these two share the name, but not necessarily the same protocol.

Was this bridge open source? Any chance of finding the name again? I know that Synchronica had (has?) a closed-source bridge between ActiveSync and SyncML.

SyncML: an introduction, its potential, its problems

filipjoelsson — 2009-04-17T19:11:18+00:00

There is an ActiveSync <-> SyncML bridge. I used it years ago with an iPAQ, and it worked ok (don't remember the name). A lot better than latter day smartphones, at least for me. The bridge let me sync with Evolution too, so no servers were needed either.

SyncML: an introduction, its potential, its problems

pohly — 2009-04-15T08:09:06+00:00

Are the specs for ActiveSync publicly available? Can it be implemented without paying royalties to Microsoft on a per-copy basis?

I looked and so far have neither found the specs nor how much it would cost to get and implement them. Considering that, ActiveSync doesn't look like a suitable alternative to SyncML for open source solutions.

Technically I cannot tell either whether it has advantages over SyncML, exactly because I haven't seen the protocol definition. I suspect that as soon as a variety of less-capable devices used it, it would run into the same issues as SyncML. Poor or inconsistent support for PIM data itself is not a problem of the protocol used to exchange it.

SyncML: an introduction, its potential, its problems

gvegidy — 2009-04-14T22:39:52+00:00

IIRC, Nokia recently announced that they will move their Outlook<->phone
synchronization on N- an E-Series to ActiveSync.

Didn't they use some kind of SyncML for this job before? Wouldn't that mean
that at least for Nokia- and Windows-phones it would make more sense to
look at an ActiveSync-based way to sync, e.g. Z-push?

SyncML: an introduction, its potential, its problems

Los__D — 2009-04-11T08:21:38+00:00

Ah, of course. DST coming along to screw things up again! :)

SyncML: an introduction, its potential, its problems

rganesan — 2009-04-11T02:54:02+00:00

> Couldn't this be solved in the (IMHO) proper way; always using UTC,
> letting clients do the conversion?

Not really. Suppose the client is in a timezone which has daylight savings in effect and set a recurring calendar item. What should happen when daylight savings is turned off in Winter? The user set the meeting at a specific hour local time not UTC. You can make the client automatically split the recurrent meeting into two both in UTC, but that causes other problems. Server has to be timezone aware to handle these kinds of cases.

SyncML: an introduction, its potential, its problems

fb — 2009-04-10T10:23:48+00:00

Nice to learn something about SyncML!

It seems the standard was built for corporate users, with the server-client architecture. To me, it seems obvious that phones should be able to sync data to each other. I guess everybody expects the hundreds of millions of "regular" mobile phones users to just lose their contacts when they get a new phone.

I have recently transfered contacts from a Samsung ?SGH-350? (a 3 year old samsung), and had to input that into a Nokia X-Press Music. Both phones had SyncML support, but now I understand that it could never work because I lacked a server. The mess increased as we had no Outlook installed (either Samsung's or Nokia's suite expected Outlook to be present). I solved it by writing some python to convert between the CSV formats. Worth mentioning that the Samsung refused to talk to Linux (i.e. Gnome Conduit).

In any case, that experience convinced me of how badly supported this kind of syncing still is.

SyncML: an introduction, its potential, its problems

Los__D — 2009-04-10T10:15:15+00:00

Couldn't this be solved in the (IMHO) proper way; always using UTC, letting clients do the conversion?

SyncML: an introduction, its potential, its problems

fb — 2009-04-10T07:58:55+00:00

The fact that the standard decided to not support an important feature seems first and foremost a flaw in the standard to me.

Couldn't this just be solved by using XML datetime format for transferring the dates?

SyncML: an introduction, its potential, its problems

stevan — 2009-04-09T15:00:31+00:00

Thanks for the info - it always had the feeling of being a problem on the verge of being solved. I left that company a while ago, and they subsequently went the crackberry route, I hope this issue wasn't used as the excuse (when the real reason, as we all know, is because suits aren't suits without their latest crackberry.) I thought using syncml with a variety of devices like that a great example of the scalability and robustness of a Free software-based infrastructure, and although stack can get a little wobbly at times, I'd be happy to put that solution in anywhere.

SyncML: an introduction, its potential, its problems

pohly — 2009-04-09T11:47:54+00:00

Stevan, most likely the calendar problems you experienced came from insufficient support for time zone information in one of the involved components. As mentioned in the article, this is not a problem of SyncML itself but of the data format used for exchanging calendar events. Support for time zones is improving, but much more slowly that I had hoped. Synthesis added support for it in their 3.x engine; not sure about eGroupware.

Many of the traditional SyncML clients only supported UTC or local time. Neither one nor the other are sufficient when dealing with recurring events in many different time zones - in other words, a multi-national enterprise scenario.

Here's a more detailed analysis of this problem: http://www.estamos.de/blog/2008/06/30/calendar-time-stamp...

SyncML: an introduction, its potential, its problems

stevan — 2009-04-09T09:57:37+00:00

Thanks for a good summary of the issues. I have deployed syncml on over 50 Palm Treos using the Synthesis utility against eGroupware's syncml capability, with pretty good results, except when it came to the clock changes, when calendar entries were often mucked about, especially recurring events. Syncml, as a piece of the building blocks that make up the service, may or may not have been to blame, but that was the one flaw that made syncing calendars fairly tense twice a year. Hunting down the issue, whether it was on the Palms, the Synthesis syncml client, the syncml code on eGroupware or the eGroupware calendar was a nightmare, never fully resolved.

But the deployment itself was extremely trivial, that's for sure.

Stevan