- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 02 Oct 2008 14:55:47 +0200
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- CC: Alan Ruttenberg <alanruttenberg@gmail.com>, Mark Nottingham <mnot@yahoo-inc.com>, W3C TAG <www-tag@w3.org>, HTTP Group Working <ietf-http-wg@w3.org>
Stefan Eissing wrote: > That is the current use there, yes. But with things like ical: and > itunes: uri schemes in OSX already, I hold any bet that we will soon see > app uri schemes spreading from the iPhone apps to the OSX apps. And then > someone will build support into FF? > > I think application uri schemes result from something lacking in URI > dispatching and maybe web arch. Taking the simple "ical:" uri scheme on > OS X, designers of web pages wanted something to say "click here to add > this to your calendar". While that is a fair use case, the design with > ical: uri schemes is a poor approach. > > Instead imagine the web page to offer additionally "click here to remove > this from your calendar". Clearly, neither the ical: uri scheme, nor the > w3c endorsed content-type based dispatching can perform the task. Would > something like > > <a href="http://example.org/event.ics" rel="calendar.add">Add this > event to your calendar</a> > <a href="http://example.org/event.ics" rel="calendar.remove">Remove > this event to your calendar</a> > > be desirable? Of course this needs some browser infrastructure. I don't think this is what the HTML anchor element and the rel attribute are for. > The alternative approach is to embedd > > <a href="http://example.org/event.ics" type="text/calendar">An > interesting event for you!</a> > > in a page and let the user choose actions from a context menu. But that > makes a very poor user interface. If the resource is served with the proper Content-Type, following this link will cause the system's calendar application to open (if configured properly). At least on my system, this causes the application to offer to add that event to the calendar. What's missing though (and here we're walking into vcarddav/calsify territory) is the ability for the calendar application not to add the event, but to *subscribe* to the remote calendar (that's what Apple does with Ical). The only thing currently stopping calendar applications from doing it is the fact that when the user agent passes the calendar object to the calendar application, the information about the origin of the object (the HTTP URL) is lost. Of course that's the same problem we had with Atom feeds, and the simple fix for this is to add the URL to the payload, as in in Atom self relation link. I proposed the equivalent for ICS in <http://lists.osafoundation.org/pipermail/ietf-calsify/2008-August/002027.html>. BR, Julian
Received on Thursday, 2 October 2008 12:56:33 UTC