Re: HTML5 proposes introduction of new family of URI schemes

I'd be interested to hear some comments on this example. As many of you 
have probably noticed, Wikipedia announced [1] within the last few weeks 
their Android application. The announcements give this https URI for 
retrieving the application binary and installing on your phone:

http://watchingthewatchers.org/indepth/1402587/announcing-official-wikipedia-android-app

As you'd expect, on desktop browsers this URI gives you a traditional HTML 
page that allows you to get the app.

What's interesting for this thread is that on an Android phone, following 
this link pops up a dialog box which gives you the choice of following the 
link in this manner, or directing it to the native application that Android 
phones use to install and manage downloaded applications.

This seems to implement the URI template model I've been asking about: 
presumably a registry in the phone has a list of such templates (they may 
just be URI prefixes, I'm not sure) such as https://market.android.com and 
(I think) http://maps.google.com for which native handlers can be registered.

This seems to me far preferable to introducing new URI schemes. What is the 
use case that new schemes handle that this idiom doesn't? As we see, this 
is already in use on widely deployed devices.

Noah

[1] 
http://watchingthewatchers.org/indepth/1402587/announcing-official-wikipedia-android-app

On 1/26/2012 5:58 PM, Eric J. Bowman wrote:
> Robin Berjon wrote:
>>
>> Eric J. Bowman wrote:
>>> Robin Berjon wrote:
>>>>
>>>> How is the web platform expected to be viable if it cannot perform
>>>> some tasks that are trivial for installed applications? In what way
>>>> is this API a protocol-layer solution?
>>>
>>> More correctly, then, it's a wholesale change to the Web
>>> architecture for no reason other than "because webmail" when a
>>> browser config hasn't even been tried.
>>
>> I think that there's some confusion and conflation going on in this
>> thread. To help alleviate it, I've created the following trivial demo:
>>
>
> OK, thanks for that, yes I was confused a bit, but not enough to change
> my point.
>
>>
>>>   If there were some empirical evidence to point to
>>> showing that everyone's a numbnut who can't figure this out,
>>> different story, but assuming that will fail before it's been tried
>>> is putting the cart before the horse (greenfield solutions are the
>>> opposite of what standardization is about).
>>
>> Just because you haven't heard of this before doesn't make it a
>> greenfield solution. It's been around a while, has been discussed a
>> fair bit, is implemented in multiple major browsers, and it's an
>> important piece of architecture.
>>
>
> I'm not talking about registerProtocolHandler(), I'm talking about web+
> schemes.  I always lurk, and sometimes participate in, the relevant
> groups where web+ was never discussed (except for Mark's blog which I
> missed).  If web+ wasn't a greenfield solution, I'd have heard of it
> before it was shipping in browsers, even without following HTML 5.
> Because fundamentally altering URI schemes would seem to be beyond the
> scope of that work to spawn, without outside review.  Reassuring me
> that Apple, Google, Microsoft and/or AOL agreed to ship it, doesn't
> assuage my concerns.
>
>>
>> And frankly, if you told me I'd have to muck with some bits of
>> configuration in my browser in order to use your site I a) wouldn't
>> trust you and b) probably wouldn't find it (on my mobile, I
>> definitely would not find it). If I did, I'd probably be lazy. And
>> I'd forget how it's done when I switch browsers.
>>
>
> Huh.  I've been explaining how to configure browsers to use e-mail
> clients to handle mailto: for 18 years now.  I see what you're saying,
> this allows Gmail to easily direct users to set it up as their default
> e-mail client.  But, do you see what I'm saying, which is a browser
> configuration option allowing webmail URIs to be entered, is either
> broken for everyone, or fixed for everyone?  What about my clients who
> insist on using CPanel webmail?
>
> When they don't get the same functionality as colleagues using Gmail,
> guess who they're going to call expecting to fix that?  I'd pass on
> their concerns to CPanel, but I wouldn't expect them to refactor into
> HTML 5 anytime soon.  It's a clever way to drive more webmail users to
> Gmail, I'll grant that, but don't expect me not to have a problem with
> it.
>
>>
>>> All developers need is markup to declare the intent "this is an
>>> e-mail address" which is solved by mailto: URIs.  Why on Earth
>>> would I want to go back and change every static Web page I've ever
>>> put a mailto: on to make it some sort of interactive API which
>>> expresses "this is the same damn e-mail address for Gmail, this is
>>> the same damn e-mail address for Yahoo, this is the same damn
>>> e-mail address for standalone clients" etc. when all I need is to
>>> declare "this is an e-mail address" which is STILL the only real
>>> intent -- declaring an e-mail addy to be an e- mail addy.
>>
>> Indeed, why on Earth would you do that, and which specification on
>> Earth did you read to come away with the impression that you'd need
>> to do any of the above?
>>
>
> I'm not getting that from any spec, I'm getting it from using my brain.
> Opening the door to willy-nilly ad-hoc URI scheme proliferation could
> result in webmail systems defining alternatives to the mailto: scheme.
> Then, guess who gets to deal with all the bug reports filed against
> legacy websites that stop working with their chosen providers?  My only
> recourse would be to go back and add to the mailto: links, by popping up
> some sort of selection box or something.
>
> Maybe I'm worrying over nothing, but this is the sort of concern I'd
> have brought up, had there been anything resembling an open process
> rather than an end-run around that process by a WG exceeding its
> charter.  You know, before it had already shipped as a fait accompli.
> Anyone with concerns now has the only recourse of crossing their
> fingers and hoping Pandora's Box hasn't been opened, or tilting at the
> browser-vendor windmill.
>
>>
>>> Handwaving won't get past the fact that this "fixes" something
>>> that's never been broken, without any regard for the ramifications,
>>> in a way that's exactly the opposite of what made the Web work in
>>> the first place.  Which was the simplicity of just marking up an
>>> e-mail addy to be recognizable as one, and leaving it at that for
>>> decades on end no maintenance required.  I don't want all my prior
>>> work appearing "broken" to visitors and domain owners because the
>>> browser vendors never even tried addressing the webmail problem
>>> with a configuration.
>>
>> I really, really wonder where you're getting these ideas from. Have
>> you considered reading the specification on this topic?
>>
>
> Yes, I eventually found the time, but the point of my participation
> here was originally just to give a +1 to an objection to the end-run
> around AWWW and any RFCs the WHATWG didn't like.  If you're going to
> prod me into speaking my mind, I will, and might even start using words
> like "collusion".  What haven't the vendors been telling us about their
> plans for web+?
>
> -Eric
>
>

Received on Monday, 30 January 2012 04:37:27 UTC