Web messaging integration

[Sean Eagan]

The currently proposed mechanism for conducting chatty conversations
with Web Intents is to pass a MessagePort as the intent "data". I see
the following problems with this approach:

* MessagePort isn't compatible with the structured clone algorithm
* requires two separate messaging mechanisms, postResult and
port.postMessage, depending on chattiness, rather than one that works
regardless
* initial data cannot be passed via `window.intent.data` since it has
to hold the MessagePort
* service needs to check `window.intent.data instanceof MessagePort`
* client cannot end or cancel the interaction, only the service can
(via postResult)

There is also no support for letting the service and UA know whether
response data is expected back. The UA needs to know this because if
it is "fire and forget", then the service browsing context should
remain open until it is explicitly closed by the user. If it is *not*
"fire and forget", the UA should close the service browsing context
and focus the client browsing context anytime the client and service
can no longer communicate with one another. In the case of "fire and
forget", the UA could even allow the user to choose multiple services
if they want. This would be similar to the "broadcast" method in
android.

Since messaging is an orthogonal issue to finding a matching service
for a given intent, we should let web messaging do as much of the work
as possible. One way to do this would be to change the optional
onResult argument to `window.navigator.startActivity` to an optional
onMessage argument, which if passed causes a MessageChannel to be
created whose port1's "onmessage" attribute is set to the onMessage
argument and returned from startActivity, and whose port2 is assigned
to `window.intent.source` in the service browsing context. If the
ports become disentangled (via either side calling its port's "close"
method or the client browsing context closing, then the service
browsing context will be closed. This approach should solve the
problems mentioned above with the current approach.

Examples:

Share:

// client: fire and forget
window.navigator.startActivity(new Intent(http://webintents.org/share,
"text/uri-list", "http://news.bbc.co.uk"));
...
// client: success response expected
var intent = new Intent(http://webintents.org/share", "text/uri-list",
"http://news.bbc.co.uk");
var onMessage = function(event) { event.data && log("success!");};
var port = window.navigator.startActivity(intent, onMessage);
...
// service
var success = share(window.intent.data);
var source = window.intent.source;
if(source) {
source.postMessage(success);
source.close();
}

Chatty intent:

// client
var onMessage = function(event) {
shouldContinue(event.data) ? event.source.postMessage(foo()) :
event.source.close();
};
var port = new Intent(onMessage).startActivity(new
Intent("http://chattyintent.org", "*", initialData), onMessage);
...
// service
var message = handleInitialData(window.intent.data);
var source = window.intent.source;
if(source) {
source.onmessage = function(event) {
shouldContinue(event.data) ? event.source.postMessage(foo()) :
event.source.close();
}
source.postMessage(foo());
}

One addition to the web messaging spec that would be nice would be a
"close" event on MessagePorts so you can know when a port has become
disentangled, which in this case would correspond to when the service
browsing context is closed.

Thanks,
Sean Eagan

[Paul Kinlan]

The latest dev version of the spec says MessagePort is Transferable and is thus part of the structured clone algorithm.

I was thinking about this the other day, for the majority of use cases chatty interfaces are not even on the radar, they mostly consist of request/response, and once you have a chatty interface there is another transfer specification needed on top - i.e, if apps sends me msg A I must return msg B etc.  If you wanted to use a chatty channel, I was envisaging the data type would be application/json+messageport or something equivalent.

If you look at Mozilla's version of the spec (https://github.com/mozilla/openwebapps/blob/develop/docs/ACTIVITIES.md), the Mediator is quite interesting for this case - and it might solve Ian Hixies case of perhaps requiring a public key to hash a key or encrypt some data.

On the subject of apps not knowing if they need to return data, I am a proponent of always calling postResult even if there is no data to pass-back, it signifies the end of an action just like closing a window would.

re:broadcast intents - this is something that we want to handle at some point but is not in the initial scope.

--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5

G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan