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

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

From: Rich Tibbett <richt@opera.com>
Date: Mon, 28 Nov 2011 14:06:11 +0100
Message-ID: <4ED38743.2090205@opera.com>
To: Giuseppe Pascale <giuseppep@opera.com>
CC: Paul Kinlan <paulkinlan@google.com>, WebIntents <public-web-intents@w3.org>, timeless <timeless@gmail.com>
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."
                   priority = 0, weight = 0, port = 80, host =
                   text = "action=http://foo.com/device/mute" 
                   text = "action=http://foo.com/device/volume" 
                   text = "action=http://foo.com/device/channel" 
# ...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);

Then the web page can send messages to the chosen device/service via the 

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:

[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 

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

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