Re: iphone urls

[ setting reply-to to the TAG, as I didn't mean to start cross- 
posting; mea culpa ]

On 02/10/2008, at 10:55 PM, Julian Reschke wrote:

> 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.

It's an interesting point, though. From the amount of interest that  
the Link header draft has received, I wouldn't be surprised if we soon  
have three things that could be used for such dispatch. If there isn't  
clear guidance about when and where to use them, they'll all be misused.


>> 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 
> >.


There are other aspects that motivate people, though. For example,  
media types have a well-known limitation in that they need to be  
implemented server-side, which often requires coordination between the  
author and a server administrator. URI schemes, from the author  
standpoint, "just work", and arguably there are many many more authors  
than client application developers in the world, so it's appropriate  
to push the pain onto the smaller and more capable party.

Just playing devil's advocate, you understand. If we don't pay  
attention to these kinds of trade-offs, we'll find the architecture  
roundly ignored, perhaps rightfully so.


--
Mark Nottingham       mnot@yahoo-inc.com

Received on Friday, 3 October 2008 00:35:35 UTC