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

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