iphone urls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

iphone urls

Stefan Eissing

Gentlemen,

load your guns. application uri schemes and posts on GET on the iPhone:

http://furbo.org/2008/10/01/redacted/

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782





Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

Mark Nottingham-4

Interesting. It would be useful to educate users as to why using URI  
schemes like this isn't a good idea, and illustrate the alternatives  
(namely, media types). I.e.,

If only we had some sort of technical architecture... board or panel  
(or even group!) to help document these things for the Web...

Seriously, though. Looking through the TAGs findings, I think most of  
the relevant documents are too dense to be useful to developers like  
this.

How about a "So You Want to Create a URI Scheme" guide, with practical  
advice about when it's a good idea and when it's not, examples, trade-
offs, caveats, and details of what this means in *existing* code?

Cheers,


On 02/10/2008, at 6:02 PM, Stefan Eissing wrote:

>
> Gentlemen,
>
> load your guns. application uri schemes and posts on GET on the  
> iPhone:
>
> http://furbo.org/2008/10/01/redacted/
>
> //Stefan
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782
>
>
>
>
>

--
Mark Nottingham       [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

Alan Ruttenberg-2
The alternative in this case would be better IPC on the iphone. My read is that the twitterific "scheme" isn't something one would use to publish on the web. Rather it's a way to hook things on the iphone so that one application can easily call a service that another application publishes. The "other" application creates an openURL handler, part of it's own application, which apparently makes the "scheme"  globally accessible.

-Alan

On Thu, Oct 2, 2008 at 5:04 AM, Mark Nottingham <[hidden email]> wrote:

Interesting. It would be useful to educate users as to why using URI schemes like this isn't a good idea, and illustrate the alternatives (namely, media types). I.e.,

If only we had some sort of technical architecture... board or panel (or even group!) to help document these things for the Web...

Seriously, though. Looking through the TAGs findings, I think most of the relevant documents are too dense to be useful to developers like this.

How about a "So You Want to Create a URI Scheme" guide, with practical advice about when it's a good idea and when it's not, examples, trade-offs, caveats, and details of what this means in *existing* code?

Cheers,


On 02/10/2008, at 6:02 PM, Stefan Eissing wrote:


Gentlemen,

load your guns. application uri schemes and posts on GET on the iPhone:

http://furbo.org/2008/10/01/redacted/

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782






--
Mark Nottingham       [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

Stefan Eissing


Am 02.10.2008 um 11:35 schrieb Alan Ruttenberg:

> The alternative in this case would be better IPC on the iphone. My  
> read is that the twitterific "scheme" isn't something one would use  
> to publish on the web. Rather it's a way to hook things on the  
> iphone so that one application can easily call a service that  
> another application publishes. The "other" application creates an  
> openURL handler, part of it's own application, which apparently  
> makes the "scheme"  globally accessible.

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.

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.

//Stefan


--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782





Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

Julian Reschke

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



Reply | Threaded
Open this post in threaded view
|

RE: iphone urls

Eran Hammer-Lahav
In reply to this post by Stefan Eissing

Pownce, a similar application to Twitter, uses the pownce:// scheme on the iphone to move back and forth between their application and their web site. This is particularly useful in their login flow which uses OAuth. OAuth requires sending users (using a browse) to their service provider for authorization (it's a delegation protocol) and are then redirected back to the calling site (to notify it can continue). In case of an desktop or mobile application, normal http callbacks would require opening a listening socket (and potentially a firewall configuration). Instead, the Pownce application asks the service provider to redirect the user back to a pownce:// url which on the iphone brings up the Pownce application. The result is a seamless integration of the application and browser.

The technical problem with this flow is that many service providers will block such urls from being used for callbacks because they have no way to verify where they will lead and if they hold security risks for the user. Since it is the remote service provider who is redirecting the user, and since the user usually have a higher trust relationship with the service provider, the user is more likely to allow that redirect to go through. Yahoo's OAuth implementation does not allow such url schemes used, or even any unverified http urls (something people have complained about).

The key is how the browser handles launching applications from a security standpoint. Content types do not offer sufficient control over the user flow, and make it more difficult to share a common content type (like an XML config schema) without opening another dialog for the user to select from. One suggestion I have seen was to use an application scheme like application://pownce/some_path. It doesn't solve any of the above concerns but at least indicates to the service provider what the intention really is.

Either way, there is a real need here and without any better (and complete) solution, people are happy to use what works.

EHL

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Stefan Eissing
> Sent: Thursday, October 02, 2008 3:34 AM
> To: Alan Ruttenberg
> Cc: Mark Nottingham; W3C TAG; HTTP Group Working
> Subject: Re: iphone urls
>
>
>
> Am 02.10.2008 um 11:35 schrieb Alan Ruttenberg:
>
> > The alternative in this case would be better IPC on the iphone. My
> > read is that the twitterific "scheme" isn't something one would use
> > to publish on the web. Rather it's a way to hook things on the
> > iphone so that one application can easily call a service that
> > another application publishes. The "other" application creates an
> > openURL handler, part of it's own application, which apparently
> > makes the "scheme"  globally accessible.
>
> 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.
>
> 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.
>
> //Stefan
>
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht
> Münster: HRB5782
>
>
>
>


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Stefan Eissing
> Sent: Thursday, October 02, 2008 3:34 AM
> To: Alan Ruttenberg
> Cc: Mark Nottingham; W3C TAG; HTTP Group Working
> Subject: Re: iphone urls
>
>
>
> Am 02.10.2008 um 11:35 schrieb Alan Ruttenberg:
>
> > The alternative in this case would be better IPC on the iphone. My
> > read is that the twitterific "scheme" isn't something one would use
> > to publish on the web. Rather it's a way to hook things on the
> > iphone so that one application can easily call a service that
> > another application publishes. The "other" application creates an
> > openURL handler, part of it's own application, which apparently
> > makes the "scheme"  globally accessible.
>
> 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.
>
> 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.
>
> //Stefan
>
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

Mark Nottingham-4
In reply to this post by Julian Reschke

[ 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       [hidden email]