Re: iphone urls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
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

Henry S. Thompson
In reply to this post by Mark Nottingham-4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Nottingham writes:

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

Thanks for the suggestion -- In fact, in response to similar
criticisms of the TAG's initial attempt in this area ([1], note this
has been languishing w/o updates for over two years, _mea culpa_)
we're trying to evolve that draft finding more in the direction you
suggest: the working title is "Dirk and Nadia design a naming
scheme".  A version should appear here in the next few weeks.

ht

[1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [hidden email]
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFI5MgakjnJixAXWBoRAtZMAJ0TBrolVd/baS1mkAthNXrx1VQpdgCfX1AS
GZsttxU3F2KCId757ANWPzE=
=KfAQ
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

noah_mendelsohn

Yes.  I would also point out that when I first joined the TAG I started to
pull together some thoughts in a draft of a finding titled "URI Schemes
and Web Protocols" the latest draft of which was written in 2005 and is
available at [1].  This was the third attempt at a draft, and I felt at
the time that we were not converging on answers.  Part of that was that,
being new to the TAG, I felt I was coming up to speed on some of the
issues, which was preventing me from doing an efficient job of getting to
the heart of the issues.  I also came to believe that there was lack of
consensus on key points, and the time did not then seem right for trying
to drive to consensus.  If you follow the links to previous drafts you'll
find that there were major changes in the presentation in each round, and
it did not seem that the third had left us much closer to success than the
first.  I do think there are some good fragments of ideas in all of them.

So, I put the work aside, with the intention that it might be picked up
either when I had a clearer sense of what should be said, or when the TAG
seemed closer to consensus on what the key messages should be.  I should
emphasize that [1] therefore does NOT represent consensus of the TAG, but
it does show some of the attempts I made to tell a story.  It's been in
the back of my mind that we should pick this up sometime, though we'd have
to be a bit careful about overlap with the URNS and Registries work I
think.

Also, note that RFC 2718 provides "Guidelines for new URL Schemes".  I
think section 2.3 is pertinent, albeit at a very high level:

------
2.3 Demonstrated utility

      URL schemes should have demonstrated utility.  New URL schemes are
      expensive things to support.  Often they require special code in
      browsers, proxies, and/or servers.  Having a lot of ways to say
      the same thing needless complicates these programs without adding
      value to the Internet.

      The kinds of things that are useful include:

   o  Things that cannot be referred to in any other way.

   o  Things where it is much easier to get at them using this scheme
      than (for instance) a proxy gateway.
------

Noah

[1] http://www.w3.org/2001/tag/doc/SchemeProtocols.html
[2] http://www.ietf.org/rfc/rfc2718.txt

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








[hidden email] (Henry S. Thompson)
Sent by: [hidden email]
10/02/2008 09:09 AM
 
        To:     Mark Nottingham <[hidden email]>
        cc:     Stefan Eissing <[hidden email]>, W3C TAG
<[hidden email]>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: iphone urls



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Nottingham writes:

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

Thanks for the suggestion -- In fact, in response to similar
criticisms of the TAG's initial attempt in this area ([1], note this
has been languishing w/o updates for over two years, _mea culpa_)
we're trying to evolve that draft finding more in the direction you
suggest: the working title is "Dirk and Nadia design a naming
scheme".  A version should appear here in the next few weeks.

ht

[1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [hidden email]
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged
spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFI5MgakjnJixAXWBoRAtZMAJ0TBrolVd/baS1mkAthNXrx1VQpdgCfX1AS
GZsttxU3F2KCId757ANWPzE=
=KfAQ
-----END PGP SIGNATURE-----




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]



Reply | Threaded
Open this post in threaded view
|

Re: iphone urls

Norman Walsh
In reply to this post by Henry S. Thompson
[hidden email] (Henry S. Thompson) writes:
> Thanks for the suggestion -- In fact, in response to similar
> criticisms of the TAG's initial attempt in this area ([1], note this
> has been languishing w/o updates for over two years, _mea culpa_)
> we're trying to evolve that draft finding more in the direction you
> suggest: the working title is "Dirk and Nadia design a naming
> scheme".  A version should appear here in the next few weeks.

Henry,

Could you stick a section in that document on "when a scheme is needed
for browser/application dispatch" or some such. Even if it's just TBD,
it's a point that I think we don't want to lose. (Apologies if you
already thought of this and have figured out the right answer :-)

                                        Be seeing you,
                                          norm

--
Norman Walsh <[hidden email]> | Upon the whole I dislike mankind:
http://nwalsh.com/            | whatever people on the other side of
                              | the question may advance, they cannot
                              | deny that they are always surprised at
                              | hearing of a good action and never of a
                              | bad one.-- Keats

attachment0 (191 bytes) Download Attachment