Re: HTML5 proposes introduction of new family of URI schemes

On Jan 19, 2012, at 18:22 , 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:

    http://berjon.com/tmp/rph.html

I've tested it in Firefox 9, though it should work on other modern browsers. When you hit the page you're offered to allow its registration as a handler for the mms: scheme. If you accept, you can then click the mms: link provided on the same page. You'll then be directed (possibly after some dialog of some sort asking you to pick your preferred handler — if you see this, pick the one that matches my site) to this very same page, and it will be able to handle your mms: link. Of course, because this is actually useful, it doesn't just work from my site to itself. Go ahead and dump an mms: link on another site, and you'll be directed to me. If I wanted to, I could actually make this a proper MMS client, and allow you to send MMSs (but there are only so many yaks one can shave in a single day).

This is essentially nothing more than streamlined configuration with a touch of security on top. It's also extremely useful.

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

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.

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

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

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 23 January 2012 21:52:41 UTC