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
>>>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 04:56:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 December 2011 04:56:49 GMT