User: Password:
|
|
Subscribe / Log in / New account

SyncML: an introduction, its potential, its problems

SyncML: an introduction, its potential, its problems

Posted Apr 9, 2009 9:57 UTC (Thu) by stevan (subscriber, #4342)
Parent article: SyncML: an introduction, its potential, its problems

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


(Log in to post comments)

SyncML: an introduction, its potential, its problems

Posted Apr 9, 2009 11:47 UTC (Thu) by pohly (guest, #6319) [Link]

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

Posted Apr 9, 2009 15:00 UTC (Thu) by stevan (subscriber, #4342) [Link]

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.

S

SyncML: an introduction, its potential, its problems

Posted Apr 10, 2009 7:58 UTC (Fri) by fb (subscriber, #53265) [Link]

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

Posted Apr 10, 2009 10:15 UTC (Fri) by Los__D (guest, #15263) [Link]

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

Posted Apr 11, 2009 2:54 UTC (Sat) by rganesan (subscriber, #1182) [Link]

> 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

Posted Apr 11, 2009 8:21 UTC (Sat) by Los__D (guest, #15263) [Link]

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


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds