- From: rektide <rektide@voodoowarez.com>
- Date: Mon, 6 Aug 2012 04:07:59 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: claes1.nilsson@sonymobile.com, whatwg@whatwg.org
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
Received on Monday, 6 August 2012 08:08:31 UTC