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

Giuseppe Pascale wrote:
> On Fri, 25 Nov 2011 12:42:00 +0100, Paul Kinlan <paulkinlan@google.com>
> wrote:
>
>> On the subject of if it should be a SOAP or JSON object you send is
>> there any difference? I only say because SOAP messages are just a
>> series of strings in its basic form. So as long as you agree that you
>> are sending SOAP messages then the strings are just JS strings so are
>> part of the structured clone algorithm and could be managed by the
>> postMessage on the port.
>>
>> Now if you want to deal with SOAP as object constructs then that would
>> be down to a library that serializes and deserializes the message. At
>> a high level I believe this can still be managed by the lightweight
>> action/datatype pair in the intent definition, the datatype being the
>> indicator to the protocol being used.
>>
>> Having said all that, I am just assuming you know the protocol that
>> you are talking and not the case where I say I want to share a link
>> and the tv is the receiver. In this case the client app would just
>> send a link to the UA via startActivity and the adapter in the UA
>> would have to know how to communicate with the user selected service,
>> which would be the TV in this case. That hardware bridge, is out of
>> knowledge area.
>>
>
> Let me clarify on this
> My question was which option we should follow when we want to send
> messages to "services" that are not web applications, so they don't run
> JS code that gets the JSON Object.
>
> To make it simple, I'll talk here about UPnP, but this is really a more
> generic problem.
>
> Is quite clear that the UA needs to partially handle the communication
> with a UPnP service, but different approaches could be followed:
>
> 1) the UA only provides to the application a URL (probably an internally
> generated one to enforce a minimal level of security) and the
> application can use an appropriate communication method (in this case
> XHR would probably be enough). This is the approach followed in our
> original proposal
> http://people.opera.com/richt/release/specs/discovery/Overview.html
>
> 2) the UPnP service is exposed to the application as it was a web
> application. The Application will be able to send messages to it using
> postMessage(). Here we have sub-options:
> 2.a) The "real" SOAP message is passed to postMessage, either as a
> message or as attribute of the JSON object passed to postMessage()
> 2.b) For each UPnP service an equivalent mapping based on JS object is
> defined. The UA then translates this into SOAP messages.
>
> I think 2.a doesn't make much sense. We should either go for 1 or 2.b
>
> The concern that was raised about 1) is security, since the UA have no
> control of what is sent to the the UPnP service (the UA doesn't even
> know which protocol the application is talking). 1) is also more
> complicated for application developers. Pros of 1) is more flexibility
> and no need to have too much supported hardcoded into the browser.
>
> 2.b) is much more simple to use for application developers and also
> gives full control to the UA on what is sent to services (so would be
> more difficult for an app to exploit bugs of the device he is
> communicating with). The cons of this is that the UA must support that
> particular UPnP service (on top of UPnP discovery,that is a different
> thing) or you would not be able to send messages to that device.
>
> option 1) may also have an impact on the intent architecture here
> discussed, while 2.b is probably transparent to intents.
>
> Finally, if one starts looking into 2.b, than you could ask yourself if
> it make sense to map this at a protocol level rather than at a use case
> level. I.e. does it make sense to have a UPnP mapping, a Bonjour Mapping
> etc, our should there rather be a a generic "playback" verb that the UA
> can translate into the protocols it support? The more generic support
> seems appealing to me but also raise questions on how to have an
> interface that is generic enough that can accommodate differences in all
> existing protocols.
>
> If is not clear by now, I don't have yet a strong preference in a
> particular direction, so inputs are welcome to see if there is a
> preferred approach that could be suitable for most use cases.

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.

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

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'});
   }
};

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?

- Rich


>
> /g
>

Received on Monday, 28 November 2011 13:06:49 UTC