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

Rich Tibbett wrote:
> 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.

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 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?

> 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.

- Cathy.

>
> - Rich
>
>
> >
> > /g
> >