SyncML Interoperability

This is a page for notes about adding SyncML support into Chandler.

---

Pointers

• Open Mobile Alliance web site: http://www.openmobilealliance.org/syncml/
  • collection of background papers and presentations at the OMA website : http://www.openmobilealliance.org/syncmldownload.html
• open source toolkit with a Python interface: http://usefulinc.com/software/syncml
• Critical Path's SyncML server: http://www.cp.net/solutions/wirelessSP/universalAddressBook/syncMLServer.jsp

• OSAF design list
  • Hamish Harvey's Oct 2003 post about SyncML and multisync

---

First Impressions Email

From: BrianDouglasSkinner

To: PieterHartsook, ChaoLam

Sent: Sat 10/11/2003

Subject: Information on SyncML

Hi Pieter & Chao,

I just spent a couple hours looking at SyncML. Here's a quick summary of my first impressions.

SyncML has noble aspirations. It's trying to be a lingua franca for keeping data in sync on wireless devices. SyncML seems like good bid at solving an important problem, but...

Like with RDF, or like with any standard, its value is all tied up in network effect. If lots of devices support it, then it becomes useful for us to support it too. But if it doesn't have critical mass, then its doesn't buy us much.

Does SyncML have critical mass? I don't know. It seems to have a lot of industry support, but I don't know what market share it has. That's the important business question, but I'll leave that and move on to technical questions...

Can we use SyncML to sync Chandler with PDAs and cell phones? You bet. I don't see any problem there. For someone who was familiar with SyncML, it might be pretty easy to get a simple Chandler/SyncML demo running. There already exists at least one open source SyncML toolkit with a Python interface (http://usefulinc.com/software/syncml). But, that said, I should warn you that doing full SyncML support would take a lot of work. There's a fair amount going on in SyncML, and there would be some real work in dealing with everything: error handling, transactions, binary format support, conflict resolution, content type capabilities enforcing, authentication, authorization, compatibility testing...

Do we need to start designing for this now, or can it wait until the last minute? My guess is that this could wait until the last minute. I think we could safely ignore the PDA and phone sync feature for another year and then tack it on later. I don't think there's anything about the Chandler architecture that's at all at odds with what SyncML needs. (Well, we would need to add in the idea of change logs to the architecture, but we're probably going to need to do that eventually anyway.) But you might want to get a second opinion from someone who knows more about networks and protocols. Andy Dent and Lou Montulli might be good people to turn to if you want to take a a more detailed look at SyncML.

Could someone start doing this now? Yes, I think anyone who wanted to could write a Chandler parcel that used SyncML to exchange data with PDAs and cell phones. Ideally that could be done by someone who's not in the building. If everything went smoothly, that person shouldn't need much architecture-level support from the OSAF staff. Maybe that's a good candidate task to add to the StarterProjects page?

Can we use it to sync arbitrary Chandler data? Yes. SyncML is agnostic about what content is being kept in sync. It can support any kind of data, including arbitrary Chandler data. However, SyncML is just the messenger. It doesn't know anything about the message. To sync with non-Chandler devices, we need to be exchanging data in standard formats, like vCard and vCalendar. In the end, the list of devices we can interoperate with will be limited not only by our decisions about sync standards (like SyncML), but also by our decisions about PIM schema standards (like vCard and vCalendar). The Chandler PIM schema will probably be difficult to change once we have UI code written against it. If one of our big goals is interoperation with other PIM apps (Outlook and Mozilla) and PIM devices (phones and PDAs), then it might be good to spend time studying the schemas that those things know how to import and export.

Could we use SyncML to do sync/replication between two Chandler repositories, either between peer-to-peer clients, or in a client/server scenario? Yes, in principle we could do that. SyncML is geared toward small mobile devices but it could be used for any type of device. In fact, Chandler-to-Chandler sync might even fall out pretty much "for free" if we've already written the Chandler code to use SyncML to talk to PDAs and phones. And SyncML seems to have some cool features. For example, it's a "high-level" protocol that can be used on top of any of a variety of "transport protocols" like HTTP, WSP/WAP, Bluetooth/OBEX, SMTP/POP/IMAP. Back in early 2003 OSAF was talking about Chandler programs exchanging data via any transport protocol: via Jabber, or mail, or TCP/IP. SyncML could do that. But that said... I very much doubt that we really want to use SyncML to keep two Chandler repositories in sync. SyncML is far more general than what we need, and I'll bet it would end up being costly to use it as our main peer-to-peer sync solution: probably costly in terms of programmer effort, and probably costly in terms of performance. But again, you'd get a better answer if you checked with somebody more experienced, like Lou or Andy Dent.

One last detail to mention... There are actually two parts to SyncML, which are:

• SyncML DS -- SyncML Data Sync
• SyncML DM -- SyncML Device Management

I think we only care about DS, not DM. The stuff I wrote here is all just talking about DS. DM is something more interesting to phone companies and service providers -- not as much of an end-user data sync thing. We could, however, think about using SyncML DM to deal with distributing Chandler parcels, or keeping Chandler distributions up-to-date in a university environment. But that's maybe biting off way more than we can chew.

Let me know if this was the sort of info you were looking for, or what would have made it more useful to you.

- Brian

---

Mitch's comments on Brian's analysis 10/15/2003

This started out with my asking whether SyncML is something we should get behind for PDA support. Brian's page is useful, valuable first step.

In an ideal world, we'd be able to go several steps further now to get our ducks lined up without having to commit resources to full development NOW. If we had the answers, then we would have reduced riskl and have a strategic direction which was fiarly firm.

Unanswered questions:

1. How real is it?
   • That is, who's using it in real products, what has their experience been, and what is the quality?
   • How much of the spec has been implemented? what are the important parts of it?
   • What is Apple using in iSync?
2. How good is the open source implementation? Is it something we could use?
3. What, if any, are the other major options besides "roll your own"?

So the issue is, should we figure out a way to take these steps now or not? It would seem to involve development resources, so that's an issue.

---

Notes from a vendor phone call Oct 15, 2003: PhoneMeetingOnSyncML20031015 Notes from an IRC chat Nov. 21, 2003 with discussion on SyncML pros and cons: http://aloha.osafoundation.org/~jbotz/irc-logs/chandler.log.20031121

Some concerns about the openness of SyncML from a yahoo groups list SyncMLissuesIP

---

Contributors

• BrianDouglasSkinner - 13 Oct 2003