[whatwg] register*Handler and Web Intents

[Greg Billock]

On Mon, Aug 6, 2012 at 1:07 AM, rektide <rektide at voodoowarez.com> wrote:
> Hi,
>
> Is there any ability to pass a MessageChannel Port in as an IntentSetting, or
> out in the success handler? Is there any facility to allow multi-part
> communications to an activity? For example, Sony does this in their Local UPnP
> Service Discovery Web Intent's scheme:
> http://www.w3.org/wiki/images/2/2e/V4_W3C_Web_Intents_-_Local_UPnP_Service_Discovery.pdf#page=15

Yes, in the web intents draft [1], the intention is that this object
implements web messaging semantics, including transferables.

[1] http://www.w3.org/TR/2012/WD-web-intents-20120626/



> This is really the only way to get out of the one-shot request/response model,
> which is extremely important to me, and the general versatility of this inter-
> perability mechanism.
>
>> The callbacks given in the method, if provided, are invoked asynchronously
>> in reaction to the handler calling success() or failure() on the Intent
>> object. We would just allow one success or failure message per Intent,
>> for sanity's sake.
>
> I'd far prefer a model not based up front on the one-shot model: a Intent
> ought be a SharedWorker in terms of interactions with the page (although more
> Intent-oriented in instantiation), crossed with the recent notion of Chrome's
> Packaged App: a stand-alone contained experience. This is a radical turn I
> would justify as due it's more general purpose interaction model. It also
> invents far less: SharedWorkers just need some interface, and presto-chango,
> we have the perfect Intents, rather than making an entirely new custom
> suite of interaction models tailored to a more limited one shot use case.
>
> I would be happy to make this proposal more concrete. Although I reference
> Packaged App as a good model, the ultimate implementation could be merely
> a new web browser page whose Window implements SharedWorker:
>
> interface SharedWorker : EventTarget {
>    readonly attribute MessagePort port;
> };
> SharedWorker extends AbstractWorker;
> interface AbstractWorker {
>    attribute EventHandler onerror;
> };
>
>
> If we want to stick on this current one shot model, I'd recommend chainable
> Intents:
>
> callback AnyCallback = void (any data, Intentable continuator);
> interface Intentable {
>    void startIntent(IntentSettings intent,
>                     optional AnyCallback success,
>                     optional DOMStringCallback failure);
> }
> Window implements Intentable;
>
> This is for this use multi-part case:
>
> window.startIntent({action:"control-point"},function(cpData,myPanel){
>    myPanel.startIntent({action:"play",data:{}})
> })
>
> Note that if the registration page does not have both of these the nested
> startIntent will fail:
>
> <intent action="control-point" scheme="?" title="RCA Control Panel"/>
> <intent action="play" scheme="?" title="Play on RCA TV"/>
>
> The desire I wish to express is creating a context which can be continued. The
> explicit use of Intentable insures that only the previous handler will be
> able to handle the new request. I'd seek a more formal mechanic to officially
> carry on the continuation: informally, cpData could hold a token which could
> be passed into the data of myPanel's play startIntent, but this ad-hoc
> continuation is a weak way of being able to hold a reasonable conversation.
>
> In parting, I wish to thank Sony for showing the utmost pragmatism in their
> design. I appreciate their two approaches to this problem, and for showing
> what a real service discovery use case looks like.
>
> Fair regards, delighted to see this topic being talked about, please let me
> know how I can aid,
> rektide