Re: A simpler, webbier approach to Web Intents?

On Wed, Feb 15, 2012 at 11:03 PM, Greg Billock <gbillock@google.com> wrote:
> On Wed, Feb 15, 2012 at 7:35 PM, Ben Adida <ben@adida.net> wrote:
>>
>> Hi folks,
>>
>> I wanted to follow up on the post I wrote about finding a simpler approach
>> to Web Intents [1].
>>
>> Looking at the latest posts, I see the following from James:
>>
>>
>>> One of the design goals of Web Intents was to eventually replace the
>>> functionality of RPH/RCH in a simpler, more intuitive fashion.  This also
>>> means eventually deprecating those methods to have a consistent API.
>>
>>
>> I'm confused by this, as it seems to be backwards. Replacing functionality
>> in web browsers is quasi-impossible. Shouldn't we, instead, be thinking
>> about how to tweak existing functionality to encompass new use cases? That
>> seems like a much safer approach.
>>
>> On my blog, Greg points to a number of long-standing discussions about RPH.
>> None of these discussions, as best as I can tell, make a solid argument that
>> we have clear use cases that cannot be fulfilled with a simpler approach
>> like RPH. Heck, even my arguments from September are about overall
>> aesthetics, not very well backed by use cases.
>
> Something we haven't talked about in a while, but which I alluded to
> on your blog, is that postMessage already has an established
> semantics: it is intended to be used for application-specific
> conversations among frames/workers that know each other well, using
> messaging defined by the application.

In the context of web-intents, the application is "cross-domain".
Nothing in the design of postMessage limits it to frames/workers that
know each other well.

> Web Intents are quite a bit more
> distantly communicating, according to much more tightly-constrained
> rules of interoperability.

There is no reason these same rules cannot be applied to cross-domain
postMessage.

>
> To bring this to the fore, what happens if you want to handle an
> intent on a page that uses postMessage? How do you tell the intents
> messages from the non-intents messages? All of a sudden we need some
> kind of namespacing on postMessage payloads, or they interfere with
> existing applications. Interfering with already-deployed apps isn't
> impossible, but it requires an extra level of motivation. There's
> already been adjustments to postMessage to make cross-origin messaging
> safer. Are we sure all existing and future uses for postMessage will
> be compatible with overloading intent delivery onto them? That seems
> to me like taking on a significant burden in the future evolution of
> postMessage, which seems to me to be doing a good job of doing the
> "user-specified actor coordination" thing.

Rather than send application payloads over postMessage(),  the
web-messaging solution is to use the global postMessage() to connect
the communicating parties over MessageChannel ports. Rather than an
in-band namespace/routing solution, the global postMessage() acts like
an out of band socket listener and then hands over the  payload work
to ports acting like sockets.

Existing postMessage applications already have to deal with
overloading, so that is not a concern for web-intents usage.

Nevertheless a postMessage based approach to web-intents (as a
supplement to a simpler and less powerful HTML solution) faces a
serious barrier: the specification of the protocol for setting up the
MessageChannel does not exist. So while I am arguing against your
claims that postMessage is technically unsuited to this use, I agree
that it is not currently ready to succeed.  I think advocates of a
postMessage solution need to solve this, concretely by re-implementing
the web-intents shim.

More important than haggling about the lower level issues it seems to
me that a clear and complete story for service registration and
discovery is missing.

jjb

Received on Thursday, 16 February 2012 16:30:26 UTC