- From: Greg Billock <gbillock@google.com>
- Date: Tue, 7 Aug 2012 16:17:52 -0700
- To: rektide <rektide@voodoowarez.com>
- Cc: claes1.nilsson@sonymobile.com, whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>
On Mon, Aug 6, 2012 at 1:07 AM, rektide <rektide@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
Received on Tuesday, 7 August 2012 23:18:21 UTC