GEEK WARNING: This post contains technical jargon and discusses a topic that will bore the daylights out of most people. Only those who think they know what this post is about based on its title should read on.
A topic I cover in a recent Collaboration Loop post is calendar subscriptions. This is something made popular by Apple's iCal program which allows Mac users to publish schedules for others to subscribe to and display on their own iCal calendar.
How iCal works is simple but it is the combination of how it leverages existing standards and the creation of a new URL schema that makes it innovative. In short, whenever you see a URL that starts with webcal:// you can be sure that it points to an Internet location that contains a calendar in iCalendar format. You should also treat this calendar as something that should be periodically checked for changes and not a calendar that is imported one time. Simple, but effective.
The challenge I had was deciding how to refer to this method in the Collaboration Loop post. I chose "webcal". My choices were to refer to this method as:
- "Techniques made popular by Apple's iCal"
In the end I called it "webcal" because there did not seem to be any better options. iCal is too ambiguous and "Techniques made popular by Apple's iCal" is too long to use more than once. Webcal was just right. I have not found any reference to this method as officially being called, or even proposed to be called, "webcal" so let me be the first to propose this name.
To understand my reasoning behind this let's first review how an iCal calendar goes from being authored on a Mac to being subscribed to by another iCal user:
- An iCal user, let's call him Nate, creates a calendar. For this example, let's say this calendar is a schedule for my favorite professional sports team; the Detroit Pistons basketball team.
- Nate instructs his iCal that he would like to publish this calendar. Since I do not have a Mac I don't have specific dialog boxes but I will assume that the configuration for this calls for the entry of a URL or, perhaps, a .mac account (which maps to a URL).
- iCal then exports the Pistons' schedule to a iCalendar-formatted file and uploads it to a webserver using the webdav protocol at the specified URL.
- Nate's friend, Kate, wants to use this calendar. Nate sends Kate an email message with the URL for the published calendar. For this example, the URL is webcal://www.example.com/DetroitPistons.ics
- While Kate is reading this email she clicks on the URL which fires up her browser. The browser recognizes the URL scheme (webcal) as something handled by an external program (iCal). It fires up iCal and passes the URL to it. (ok, again, I don't have a Mac so the email program may invoke iCal directly, not important to the flow of this story, stay with me).
- Kate's iCal first adds the URL to its list of subscribed calendars. It may also download the calendar for the first time using http. In fact, the URL used for the actual download is the same as the URL above except http is used instead of webcal; http://www.example.com/DetroitPistons.ics
This is a critical point to note. The webcal:// URL schema simply tells Kate's browser to pass the URL to an external program, iCal. It does NOT tell Kate's browser to download the file.
If Nate sent Kate the url with an http:// instead (http://www.example.com/DetroitPistons.ics) Kate's browser would simply try to download the whole .ics file and do something with it. Assuming the webserver's mime types are configured correctly this would cause the events in the .ics file to be imported into a calendar. Which is not what what Kate wants to do. She wants to subscribe to the calendar so any changes are updated on her copy.
- Now that Kate has subscribed to Nate's Pistons calendar Kate's iCal will periodically download the Pistons' calendar using http. If it is coded correctly and behaved like a good citizen of the Internet (like I expect iCal is, but I can't verify) it would save the date of the last calendar change and only download the whole calendar after noticing that the date is newer. This important piece of information is provided by the http protocol and avoids unnecessarily downloading the whole calendar file.
- iCal then reads each event in the calendar, matches it up with the version of the event it downloaded previously, and updates the calendar if it has changed (or was added or deleted).
So, if I have not lost you by now, you should recognize that an iCalendar file specified with an http URL scheme is handled differently than one specified with a webcal URL scheme.
- The http URL scheme causes the browser to download the entire file and then hands it off to an external program, which would import the calendar events.
- The webcal URL scheme causes the browser to handoff the URL to an external program. It is up to the external program, in this case iCal, to add it to the list of subscribed calendars.
Many of you probably feel that I should just call it "iCal". But that is too ambiguous for the following reasons:
- This is the name of an Apple product, not a method.
- iCal is often used as a short-hand name for iCalendar, the standard file format. To see what I mean read Wikipedia's definition of iCal . Although iCalendar provides a piece of this innovation it does not sufficiently describe it and is still too ambiguous.
To make matters worse even vendors aren't consistent in describing this method:
- For some reason Trumba's Public Calendars have an ICAL link that uses an http URL scheme which simply imports events and does not subscribe.
- Airset seems to get it right. It offers two links. One to download the calendar (using http scheme) and the other to subscribe (using the webcal scheme).
- Microsoft's Windows Vista page goes out of its way to completely describe what it does in three paragraphs.
- IBM's recent announcement is quite vague on what support for iCal really means. It took this blog entry from someone who attended Lotusphere to clear up the ambiguity for me.
In the end "webcal" seemed to describe it best.
Does this make sense or did I miss something?
It is interesting to note that rss and atom might have benefited from the URL scheme approach; perhaps call it rss:// or atom:// but instead the standard that emerged uses embedded "link rel"s to indicate an associated feed. Using a URL scheme would have been much simpler but browser support is the big issue. Another topic for another day.