Three Architectures for Mobile calendaring/email connect

Peer-to-peer (P2P)

This is the traditional way to communicate calendar and email information between mobile devices and other devices. The mobile device typically connects to a desktop or laptop machine with a physical cable or proximity connection (e.g. bluetooth).

Originally P2P updating was entirely unstandardized but today many mobile devices support SyncML, and some of them support iCalendar over SyncML. Sometimes regular PC calendar applications support this, sometimes users have a specialized PC application just for synching the calendar to the device. I believe that it's fairly common for a user to maintain their calendar in an application like Outlook but synch it with an adjuct application.

There do exist generic SyncML applictions and servers (e.g. jataayu, teamware) that can take the place of having synch operations directly in the PIM -- presumably these work with exported data files or through having connectors to talk to the most common calendar server vendors.

The consilient folks say that SyncML is "heavy" and that the iCalendar parsing isn't consistent so what seems like an application that can be written once and run against many devices actually requires specialized code for quite a few common devices.

Note that SyncML can also synchronize certain types of data between a client and server (article). However it's not fully an access protocol the way CalDAV is.

P2P is the only model that works for non-network-capable devices. Issue: How prevalent are these devices today? In 2 years? How often do their users actually synch (using cables) or do most owners of these devices have the expectation of using them standalone?

WebUIs or Dumb client-to-server (WEB)

It's pretty common for both specialized and general applications to have WebUIs specialized for mobile devices with their limited display screens and limited browser functionality. I believe this is typically done as a parallel WebUI.

The problem with doing email and calendaring applications this way is that the affordances suck for users.

Recently "Opera Mini" was announced: a Web browser for mobile clients running Java + GPRS. It's configured to talk to a proxy service hosted by Opera which does the heavy lifting of translating conventional Web pages to a more mobile-friendly format. I wonder how it does with very active pages like gmail?

Smart Client-to-Server (C2S) -- CalDAV

Today P-IMAP is used in email mobile applications to enable smart online email applications. Thes applications connect directly to the email server and synchronize email for later use. With this kind of application, the user doesn't have to remain connected to use the application interface. C2S applications are now possible for calendaring because of CalDAV.

The presence of an Internet server, along with the ability to synchronize data for offline use, make this architecture the best for maximizing availability of up-to-date information to the mobile user.

Support for multiple clients (present in both P-IMAP and CalDAV) make this architecture capable of handling N-way synch, not just between one PC and one device.

Because CalDAV is new, what are the prospects for seeing mobile CalDAV clients?

• Nokia participates in the standards activities here -- we are pinging our Nokia contacts to see if they have public plans.
• Consilient (Blackberry applications) is interested and following up with me in a couple weeks after they read up on the standards
• ISAMET has a proof-of-concept phone client implemented using J2ME (Java 2 Micro Edition).

Since SyncML can also be used C2S, there's a possibility for CalDAV servers to also support SyncML for mobile devices that today only speak SyncML (though it's not clear that the transport protocol for SyncML is that consistent). This can be much easier than supporting SyncML on the user's computer -- the server is managed by IT and IT can easier diagnose problems, install new connectors, etc. OTOH that only works for network-capable mobile devices.

Comparison

Survey of mobile client platforms

For the C2S architecture to work somebody needs to build an application to operate on the mobile device. With new standards like CalDAV we're likely to see add-on application support first (requiring users to download software that runs on the platform of their existing mobile device). Later, with an application as popular as calendaring, I'm guessing we're quite likely to see devices come with standards-compliant calendar applications built-in. But in the meantime, naturally the market share of different client platforms is of interest here.

• Canalys, global: Also Nokia expected to extend offerings and market share in enterprise and with demand for email support. Palm 2nd place, RIM (Blackberry) 3rd place. This means Symbian (Nokia, Fujitsu) is by far the top platform.

• IDC, July 2005, Western Europe: Again, market dominated by Nokia.

• IDC, July 2005, Western Europe: Symbian top with 56% of devices (and growing), Windows mobile 12.7%, Linux 11.3%.

Now J2ME sits on top of the device's operating platform so it's actually got broader support than Symbian itself. Much like with PCs, applications developers have the choice of the more powerful and direct native platform interface (e.g. Symbian C++) or the cross-platform Java framework.

• Developer advice on mobile applications

• Extensive list of J2ME phones

Is J2ME powerful enough? ISAMET's proof-of-concept client shows it is although it pushes the limit of memory consumption of this generation. This client implements not only the CalDAV protocol but also iCalendar parsing including recurrence expansion (a feature some have considered difficult for mobile devices) and timezone handling.

SyncML^? and CalDAV^?"> Head to head: SyncML and CalDAV

Major caveat: I'm biased.

Both SyncML and CalDAV can be used with a client-server model. Mobile devices could support either protocol as a way to access a calendar. Servers could even support both CalDAV and SyncML. Which is better for mobile devices?

One first answer to that question is that maybe we don't need to decide. Both SyncML and CalDAV exist, for different reasons, and mobile device application developers can make their own decisions based on their investment, expertise, and the suitability of each protocol to their use cases.

That is really a way to avoid the question, however it does indicate that the answer might depend on a number of factors.

• Does the mobile app need to browse other peoples' calendars? If so then CalDAV is better because SyncML does not allow for browsing.
• Does the mobile app need to set ACLs or grant permissions? If so then CalDAV is probably better but I may not know enough.
• Does the mobile app need to do scheduling? CalDAV better...
• However if the mobile app doesn't need any of this then SyncML may be easier to implement.

OSAF's current plans

Chandler: Support for mobile device P2P synch is not in the Kibble or Westwood plan for Chandler, nor are we resourced to do this. We don't have enough people to extend the scope of work right now, nor do we have experts on mobile devices or the vision to achieve something interesting here.

Scooby: Support for reduced WebUIs (WEB architecture) to support mobile devices is not in the 1-year plan for Scooby.

Cosmo: Since support for CalDAV is underway, Cosmo already supports the C2S architecture. We will do testing with mobile device client applications as they become available (e.g. ISAMET's).

Other: OSAF has some interest in developing a CalDAV-capable application to run on mobile devices. Note, however, we don't have the resources to do this -- we don't have excess development staff nor does our development staff have expertise in J2ME, Symbian, etc.