[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