Re: iphone urls

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