[whatwg] register*Handler and Web Intents

rektide rektide at voodoowarez.com
Mon Aug 6 01:07:59 PDT 2012


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

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



More information about the whatwg mailing list