Re: A simpler, webbier approach to Web Intents?

On Feb 15, 2012, at 8:14 PM, John J Barton <johnjbarton@johnjbarton.com> wrote:

> Just a conjecture based on reading both sides:
>  <intent> solution favors HTML writers and simple use cases
>  'webbier' solution favors JS writers and more complex cases.
> 
> I doubt either side will find the other acceptable.   The HTML
> solution will be very limiting; The JS solution probably can't be
> simple enough; JS devs have plenty of horrible experience with writing
> DOM tags for funky reasons; JS is intractable to web search tools.
> 
> Any chance of common ground beneath a two-headed solution?

Intents enables better shell registration in file system managers. One can right click, and Send to, or open with. At present, I still can't register a magnet link handler with RPH. The web+ prefix seems a bit of a flop, and the whitelist is too limited.

Hixie has posted consistently in support of the register* APIs.

I've just not had success with them. I am trying to have my webbier (low level) postMessage cake.

That's meeting in the middle, for me. I've had two goals: proving intents over web messaging, verifying accessibility.

I just don't see RPH working at a platform level. Web Intents however, that can work. RPH just hasn't seen implementation uptake. We are seeing good work with blob uris.

I do have something of an RPH use case: I use postMessage to transfer blob Uris across origins; with those, those Uris I then request again from frames when I need the blob data sent.

So I could register web+blob for my uri brokerage. But I'm not going to. I'm going to use shared workers and postMessage. It's more reliable for me as an author.

I think RPH wasn't sustainable on the platform level, it offered too little in the UA level. I do hope it'll be reused later in an extensions namespace, so we can register protocol handlers as part of  trusted apps.

If RPH were absolutely necessary, it could be hacked into intents, just call it webintents.org/protocol, or even, whatwg.org/protocol.

Received on Thursday, 16 February 2012 05:49:34 UTC