W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

Re: How can we implement UPnP service communication with intents?

From: Clarke Stevens <C.Stevens@CableLabs.com>
Date: Wed, 30 Nov 2011 21:55:31 -0700
To: Rich Tibbett <richt@opera.com>, "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>
CC: "public-web-intents@w3.org" <public-web-intents@w3.org>
Message-ID: <CAFC55A1.15B0C%c.stevens@cablelabs.com>
I'm still thinking about what level the intents should be (or if we care).
However, we do have to consider the user experience. When a user is
sitting in front of a television the expected experience is that a
volume-up command followed by a second volume-up command are extremely
likely to mean volume-up on the same device. Maybe this is managed in the
application, but if we don't consider this "persistent" relationship, we
are bound to make mistakes in the interface design.

On 11/30/11 6:17 PM, "Rich Tibbett" <richt@opera.com> wrote:

>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
>>> for these types of virtual services so the UA can relay information on
>>> 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
>>> services (or an SSDP Search request) and then receives back some
>>> 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."
>>>      TV2._http._tcp.local.
>>>                     priority = 0, weight = 0, port = 80, host =
>>>      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"
>>> # ...etc
>> If multiple actions from the same device are mapped to different
>> wouldn't the user be asked to pick the TV the first time he wants to
>> volume, and then again when he wants to change the channel [for the
>> 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
>> 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."
>     TV2._http._tcp.local.
>                    priority = 0, weight = 0, port = 80, host =
>     TV2._http._tcp.local
>                    text = "action=http://dahut.io/tv/" "path=/"
># ...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
>>> 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
>>> 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
>>> 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
>> was started with the volume intent, but the message being sent is for a
>> action. Is that a typo or is it how you envision it to work - that you
>> send actions other than the intended one once the message channel has
>> 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'
>>> via the MessagePort mechanism:
>>> GET 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
>>> sending on to the real device (since in this model, we could have
>>> 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
>>> 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
>>> 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
>>> Web Intents base specification. Perhaps we want to tackle that in this
>>> 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
>> - Cathy.
>>> - Rich
>>>> /g
>Rich Tibbett
>Opera Software ASA
Received on Thursday, 1 December 2011 04:56:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC