Another new calendar: Mediabee

• Targetted to home calendar -- doesn't try to replace Outlook at work
• Uses invitations (iMIP) to synchronize events on home and work
• Doesn't offer PDA synch
• Doesn't mention CalDAV anywhere

Airset

• Does offer PDA synch as a free service along with storing your calendars online
• I should get a new phone to be able to test this kind of thing

Mobile device support

CalDAV^? client"> Technology Demo: CalDAV client to run on J2ME mobile devices

If OSAF is a technology demonstrator, then this plan offers the ability to exceed people's expectations for calendaring on a mobile device. This client offers features that users haven't had before:

• Synchronize and make changes to calendar any time an Internet connection is available -- not just when near PC.
• Browse public calendars
• Synchronize or browse calendars of friends, family or coworkers
• Send invitations to meetings any time

Note that Java is a second-class API on these phones -- it doesn't give access to the native calendar database on the device. That's why Cyrus was forced to write a mobile GUI for his demo. Corby Wilson is working on a calendar application that would be burned onto ROM...?

Cell data networks are being seriously enhanced these days -- e.g. article on EDGE

Another proof-of-concept in AirSet^?, described by Mossberg -- AirSet^? could even be using CalDAV (but almost certainly aren't) to make their Palm client synch to AirSet^?'s service

Meeting Needs: PC application to synch to mobile devices

If OSAF is more concerned with gaining broad adoption of Chandler, then a way to synch to non-Internet-capable devices is key. This is just a basic requirement for many people to use a PC-based calendar.

A lot of the limitations in this approach is that it relies on using the calendar application already on the mobile device. So you could set up something for SynchML^? to synchronize multiple calendars (mine, my husbands, my boss's) but the mobile device is unlikely to be able to display that.

SynchML^? definitely doesn't do scheduling or browsing and wouldn't do a good job of multiple calendars even if the mobile application supported showing multiple calendars.

Bernard says there are four SynchML^? profiles. One allows to configure a username, password and URL to the HTTP SynchML^? server. Another for events, contacts and tasks -- configure relative URLs to the server for each of these. E.g. http://synchml.oracle.com:666/bdesruisseaux/contacts and etc. There are also options for slow synch, incremental synch. Bernard uses one profile to synchronize his calendar and another for his addressbook. Sometimes the synch messes up and he's forced to do a manual slow synch of one or the other.

Note that with SynchML^? the server (which may be the PC) maintains all of the mobile client's synch state. (For a public calendar server, this makes SynchML^? impossible to use.) A unique identifier is assigned for every single device because a user may have more than one device.

SynchML^? details

Learning more from Chris Dudding and Cyrus Daboo...

SynchML and multi-author support: conflict resolution mechanisms exist but it depends what kind of synch you're doing.

• One option is for the SynchML^? server (which may be the PC) to overwrite the device's copy
• One option is for the device to overwrite the server's copy
• There's also two-way -- you can have partial failure, detecting that a resource was changed in two places.

SynchML and browsing: this isn't strictly possible but you can run a synch in order to be able to browse something.

Filtering: There are only limited features for downloading partial data with SynchML^? and these features are quite new. So the normal model is to download the whole calendar. Contrast with IMAP where it's possible to download headers first, or with CalDAV where the client can choose to synch attachments or not, attendees or not.

ACL: no way to manage ACL from the device over SynchML^?.

Scheduling: no way to create invitations on the device and use SynchML^? to deliver -- have to do something different

Positive features: SynchML^? is not limited just to calendaring -- also vcard

Poor extensibility: it is quite specific about which properties can be handled (e.g. the synchML specification for doing contacts can't handle just any compliant VCard file, it can only handle a known subset. ) This makes extensions difficult to use -- the SynchML^? server (the PC) has to filter out extended properties and so the mobile device may not even have the opportunity to use. Note that most devices support VCalendar, not iCalendar -- the more primitive format.

Collecting "gut feels"

I asked Cullen (no particular experience in this area but good experience scoping projects) for his gut feel comparison of the amount of effort to do this compared to a CalDAV client, and his estimate was that the SynchML^? work was a tiny fraction of the effort.

Todd estimated 1/3 effort ratio for doing a synchML client solution compared to a CalDAV client but preferred the network-centric solution -- believing that people are going to have more network-capable devices and fewer local-synch-only devices in two years time.

Katie thought doing both was probably the best coverage.

Cyrus thought that assuming J2ME, but also having to port to PalmOS^? indepedently... with some special work to put the data directly in the calendar store so you don't have to write new mobile GUI... Cyrus thought that the amount of effort might be about the same!! but naturally the result is quite different. OTOH if you do have to write the GUI for the mobile device (so that you can use iCalendar and view multiple peoples' calendars or other benefits) it would be a better application but take 3 times the effort of either of the data-connector projects.

Chris Dudding agrees that writing a complete GUI/application on the device is several times the amount of work -- dealing with different screen sizes and input characteristics of the different devices makes a GUI very hard to write. Comparing the synchML plugin to the native CalDAV synch utility are roughly the same amount of work but obviously different operational characteristics.

What about blackberries?

Blackberry devices are the toughest nut to crack because of the company's proprietary approach to protocols. Yet because there's an Exchange server connector available, any calendaring solution that could replace Exchange now would have to support blackberries somehow.

Some interesting questions to ponder:

• How widespread are these devices now? More importantly, users might be key corporate decision-makers so even if the number of users is somewhat low they still might be important.
• Where is the market going in two or four years? Nokia is trying to eat blackberry's lunch in the email area, what effect will this have on the market?

Code reuse?

http://wiki.mozilla.org/Calendar:Device_Sync