- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 01 Dec 2011 02:17:24 +0100
- To: Cathy.Chan@nokia.com
- CC: public-web-intents@w3.org
Cathy.Chan@nokia.com wrote: > Rich Tibbett wrote: >> I actually feel that the only absolute requirements on UAs would be to >> a.) listen for (via DNS-SD/SSDP discovery mechanisms) and emulate >> discovered services as virtual Web Intents and b.) define a standard channel >> for these types of virtual services so the UA can relay information on to >> these >> services via HTTP when they are connected to a web app. > > That's a very good starting point. > >> The following is the flow I'm envisioning... >> >> The UA sends out a multicast DNS request asking for current Intent-based >> services (or an SSDP Search request) and then receives back some devices >> available (the service type is TBD but in this example we call it >> '_intents._tcp' >> that has some well-defined TXT-record syntax for Intents). e.g.: >> >> > nslookup -q=any "_intents._tcp.local." >> # START OF FIRST RECORD >> TV2._http._tcp.local. >> priority = 0, weight = 0, port = 80, host = 10.0.0.231 >> TV2._http._tcp.local >> text = "action=http://foo.com/device/mute" >> "path=/tv/mute" >> TV2._http._tcp.local >> text = "action=http://foo.com/device/volume" >> "path=/tv/volume" >> TV2._http._tcp.local >> text = "action=http://foo.com/device/channel" >> "path=/tv/changechannel" >> # END OF FIRST RECORD >> # ...etc >> > > If multiple actions from the same device are mapped to different intents, > wouldn't the user be asked to pick the TV the first time he wants to change > volume, and then again when he wants to change the channel [for the first > time]? Would it make more sense for the intent to be associated with the TV > itself? I know this is just an example, but the underlying question remains: > what's the level at which the intents should be defined? The level of abstraction is entirely up to the defined action type. The messaging transformation - from web app to virtual web intent to HTTP service and back - would remain consistent. Here's another example at a different abstraction level: > nslookup -q=any "_intents._tcp.local." # START OF FIRST RECORD TV2._http._tcp.local. priority = 0, weight = 0, port = 80, host = 10.0.0.231 TV2._http._tcp.local text = "action=http://dahut.io/tv/" "path=/" # END OF FIRST RECORD # ...etc The action 'http://dahut.io/tv/' defines a more complex message channel structure that allows for muting, volume control and channel changing. > >> The UA then adds each intent service discovered to the index of available >> Web Intents and assigns each of these intents the well-defined type of >> 'application/octet-stream+web_intent'. >> >> A web page requests one of the intent verbs and connects to one of these >> virtual intents (which may be the device discovered above or another >> device/service from elsewhere): >> >> var channel = new MessageChannel(); >> var intent = new Intent('http://foo.com/device/volume', >> 'application/octet-stream+web_intent', channel.port2); >> navigator.startActivity(intent); >> >> Then the web page can send messages to the chosen device/service via the >> channel: >> >> port1.onmessage = function(msg) { >> if(msg.data.action=='connected') { >> port1.postMessage({'action': 'mute', 'value': '1'}); >> } >> }; >> > > This is somewhat related to my question above. In your example, the activity > was started with the volume intent, but the message being sent is for a mute > action. Is that a typo or is it how you envision it to work - that you can > send actions other than the intended one once the message channel has been > established? This was a typo in the original email :( The example should have been the following (or whatever message format the 'http://foo.com/device/volume' action comes to define): channel.port1.onmessage = function(msg) { // do something with msg // set volume to 20/100ths. channel.port1.postMessage('20'); }; > >> The UA will then relay this posted data to the device via HTTP according to >> a >> well-defined rule for handling 'application/octet-stream+web_intent' data >> via the MessagePort mechanism: >> >> GET 10.0.0.231:80/tv/volume HTTP/1.0 >> ... >> [blank line here, followed by message body] >> [{'action': 'mute', 'value': '1'}] >> >> The receiving device will then interpret this message or transform it for >> sending on to the real device (since in this model, we could have service >> management middle-ware on the same host as the UA or service >> management middle-ware devices doing the direct service communication). >> >> If we want something like this then there is a bit of work to do to define >> the >> DNS-SD/SSDP service types for Web Intent services and how the UA will >> emulate those services as Web Intents for use by web apps. >> Everything marked 'well-defined' in the above is negotiable but this would >> be >> one method of hooking up devices to web applications via Web Intents. >> >> Defining these necessary parts will warrant a separate spec on top of the >> Web Intents base specification. Perhaps we want to tackle that in this group >> as a separate activity? > > It could even happen in the DAP WG instead of the Web Intents TF, not that I > have any preference either way. Where we could explore this further is a little unclear right now but I'm open to suggestions and other proposals for device communication in general. Thanks, Rich > > - Cathy. > >> - Rich >> >> >>> /g >>> > -- Rich Tibbett Opera Software ASA
Received on Thursday, 1 December 2011 01:18:10 UTC