Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard <chuck@jumis.com> wrote:

> **
> Does anybody use registerProtocolHandler in any real sense? Is
> registerContentHandler needed? It seems like Web Intents is an evolution on
> the concept. I don't think we're going to see convergence on those old
> methods. I'm ready to leave them both in favor of a yet-to-be announced
> candidate (web intents).
>
> URIs are better than protocols,  and Intents are better than content
> handlers. In my opinion.
>

RPH seems to be intended primarily for mailto: (I think that's where it is
used.) I'm not sure what the RCH usage is like. It is definitely possible
to imagine mapping UA handling of mailto: onto web intents. The way I think
of it is like this: RPH is basically an action with a payload. RCH is
essentially type info with the payload. Web Intents is kind of off-axis
with both an action and a type as well as the payload. The idea (taking
inspiration from the pluggable usage in the Android ecosystem) is that the
action (analogous to the "protocol") is a locus between the client and
handling service which can be messaged to the user in a well-understood
way. (i.e. instead of just saying "here's some data, do whatever you want
with it," which is a more content-type-driven


As far as I can tell, the model doesn't prohibit, nor does it encourage,
> the passing of MessageChannel.
> It's very much made for an RPC style of communication, but if the message
> being passed back is a channel, well that's just fine.
>
> Am I mistaken? What I'm seeing is that we get MessageChannel for free, and
> there's no need to specify further.
> Individual Intent authors can do that themselves.
>


Yes. We envision RPC-style request/response as the sweet spot for intents.
We've definitely considered use cases which are better served by opening a
persistent channel. It isn't clear to me as yet what to do about those.
They definitely imply a more well-specified protocol to be pursued over
that channel. Web Intents as an API doesn't really include or exclude that
in the current form.

On the other hand, it'd be a really nice application of the Web Intents
permissions mechanism to be able to connect up, say, an SSH connection
using Web Intents, so that I could write an in-browser terminal which could
then be attached to a secure socket by the user.

At this point, I'm not sure whether this kind of persistent connection use
case is far enough from Web Intents to want to exclude it, or close enough
to want to include it explicitly. Our early belief is that we aren't ruling
it out with the proposed API, since MessageChannels could be provided or
returned in the payload data. On the other hand, we haven't chosen to
explicitly include such usage.

But a lot of this stuff just comes with nice platform integration; I just
tried passing Blob objects through intents in Chrome Tip-of-Tree with our
prototype, and it Just Works, allowing a really appealing vision into what
"upload" intents and file interactions could be like. Wins like that make
me think that focusing on the sweet spot RPC interaction will not paint us
into a corner.

-Greg