Re: A simpler, webbier approach to Web Intents?

On Thu, Feb 16, 2012 at 8:29 AM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
>
> 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.

I'm not saying it's technically impossible to pass cross-domain
messages through postMessage -- it's obviously intended for that
(although even that application has caused concerns in the past
leading to targetOrigin). Just look at docs around targetOrigin,
though: the modeling of the feature is that the pages are working
closely together through their own application-specific messaging
interface.

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

Let's see a concrete proposal.

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

The web-messaging concept that ports can be capabilities-driven
channels to provide applications the ability to loosely couple is one
that's very similar to the goal of web intents. The central nub of
that problem, however, isn't the communication mechanism, it is the
format of the messages and the service discovery mechanisms. Those are
the problem facets web intents starts with. We also think the problem
needs to be scoped to include loosely coupling web apps with
browser-initiated and local system-initiated events. Starting with
those concerns, I don't think messaging channels are the most natural
solution. Messaging channels are a solution if the problem is "how
could we possibly arrange arbitrary communication between two web
pages." But the problem web intents is trying to solve is more
structured: "how can web applications participate in fulfilling a
single user-oriented task."

What's more, if it turns out that establishing message channels is
really valuable, the web intents API is so simple it's going to be a
good solution for solving the registration/establishment problem
there:

var channel = new MessageChannel;
navigator.startActivity(new Intent("http://webintents.org/connect",
"type-of-service-I-want", channel.port1));

The web intents proposal explicitly wants to support this kind of use.
We, the authors, think that more structured intents will end up being
more valuable, but we're explicitly in favor of allowing generic
connection establishment to exist alongside those more structured
intents. In addition to being very compact and developer-friendly,
this mechanism brings along all the semantics of user selection,
assumed support for defaulting and automation, dynamic extensibility,
and so forth that are already part of web intents.

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

Do you mean that a proposal for discovery and registration of these
ports as above is missing? I agree with that, but I think our proposal
for registration and discovery of web intents service is quite
concrete (concrete enough to actually be implemented!). And as above,
I think it ends up being a good solution for discovery for
establishing these channels, if you wanted to build that.

-Greg

Received on Thursday, 16 February 2012 19:22:19 UTC