I’ve seen half a dozen conversations sprout up about adding iCal.app support to one of the open source web calendar. Most peole want to be able to publish from within iCal.app and have it show up on the web, in something a little more dynamic then a text file. This is easy, and only a matter of time. (in fact, looking at the iCal Blog, looks like the one already exists) Shortly some of the more established projects like Kronolith or the various PHP groupwares, will support it.

Some people want to be able to go the other way, subscribe to their web calendar, and have it show up in iCal.app (or Mozilla calendar). This makes sense for: public event calendars like Protest.net, and for tracking the schedules of your nearest and dearest.

What everyone is going to eventually want, is a two-way connection. Right now the relationships are all uni-directional. If you’re publishing a calendar, then you aren’t subscribing to it, and visa versa. So you are stuck either only editting events locally, or only editting them remotely, but not both. Thats intolerable.

The 3-file Hack for Pub/Sub iCal: Worse is Better

Well there are a number of good, technical solutions involving smarter protocols, like CAP, that would solve this problem for us. However its taken 5 years, and Apple (doing for iCal like they did for 802.11b, USB, and a floppyless world), to get us to the point where anyone is using iCalendar even in its most basic form, so lets not hold our breath on CAP adoption. Lets see if we can think of a solution right now.

One solutions that occurs to me is have 3 calendars (or at least .ics files) masquerading as one.

  • My_Calendar_in.ics – where your can publish all the events you’ve locally created.
  • My_Calendar_out.ics – where your web cal publishes all the events created remotely.
  • My_Calendar_public.ics – which collates the above 2 files, and is the url you hand out to the outside world to subscribe to. This would be maintained by the web cal, which is outward facing view of the app.

This scheme is limited in that you still can’t edit a file on your desktop, that you created on the website, but its simple with what we have installed, and I think its an 80% solution.

And given that SyncML won’t be supported in version 1 of the already delayed iSync, we’re going to need to build our own open solutions, for at least a while.