- From: Greg Billock <gbillock@google.com>
- Date: Thu, 17 Nov 2011 17:15:34 -0800
- To: Charles Pritchard <chuck@jumis.com>
- Cc: public-webapps Group WG <public-webapps@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
- Message-ID: <CAAxVY9dps-=PgaoYNnT+LLYUOwrQtiiUxYUP7kASuRRCfWZ_0A@mail.gmail.com>
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
Received on Friday, 18 November 2011 01:16:09 UTC