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

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 UTC