How can we implement UPnP service communication with intents? (was: Re: intents broker == user agent ?)

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.

/g

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 28 November 2011 11:25:39 UTC