Mapping UPnP/Web Intents

** adding intents list again into the loop **

Hi,

Disclaimer: while I use UPnP in this thread, that is just one example and  
this discussion can be generalized.

On Tue, 20 Mar 2012 10:51:39 +0100, Nilsson, Claes1  
<Claes1.Nilsson@sonymobile.com> wrote:

> A mapping according to your proposal below seems reasonable. However, I  
> am not sure on the use case here. You stated earlier that you wanted to  
> avoid that the Client side developer has to implement complex UPnP  
> communication so should the video playback be controlled in this  
> scenario?
> * Control buttons in Client page meaning that this page has to implement  
> UPnP communication directly with the other device ?
> * Control buttons in Client page meaning that the UA implements a  
> mediating Service that talks a simple high level protocol (over HTML5  
> channel messaging) with the Client and UPnP with the Service device?


I think we should aim for both:
- hook "simple" intents on home devices, e.g. "view" is translated into a  
play action for a UPnP device
- allow more complex app<->device interaction, for more complex scenarios

In many cases, application developers will have no skill (and no need to)  
implement communication for each specific protocol. The UA can take care  
of that.
For more complex use cases one can attempt the low level UPnP  
communication.
Maybe this will even be disabled by default in some browsers due to  
security concerns, but could be used in more controlled environments, or  
in things like extensions, widgets and so on that have an "installation"  
step where the user has to explicitly authorize the application access to  
the home netowrk.

> * Control buttons in a Service web page meaning that this Service page  
> has to be registered by some method. If we want to address existing UPnP  
> devices with unmodified Device descriptions how do we register this  
> Service page? Could existing elements (manufacturer, modelName, UDN???)   
> in the Device description page be used as input to a question to a some  
> server in the cloud (“Sony device database”) that intelligently uses  
> these elements to return a page that contains the registration markup  
> for the Service page??
>

I don't think we necessarily need to the intent declaration somewhere. If  
we manage to just map the same tags of the intent declaration on existing  
UPnP service description properties, that would be enough for a UA to  
expose these service as they were Web Intents. Don't you think?
Of course, if we don't manage to achieve this mapping, we will need to  
define some extensions to UPnP.In that case we should reusing the existing  
UPnP template for services though. maybe just add the additional  
parameters we need rather than copy/paste the intent declaration.

/g

> ________________________________________
> From: Giuseppe Pascale [giuseppep@opera.com]
> Sent: Tuesday, March 20, 2012 9:20 AM
> To: Nilsson, Claes1
> Subject: Re: HN and Intents
>
> On Tue, 20 Mar 2012 08:31:13 +0100, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
>
>> Thanks Pascale,
>>
> Giuseppe ;)
>
>> Good points.
>>
>> I agree that an impotant requirement is the ability to access existing
>> UPnP devices. Yes, to keep it simple for Client application developers,
>> i.e. they should not have to speak UPnP/DLNA commands, and at the same
>> time use existing UPnP devices a mapping to Web Intent service using
>> elements in a current UPnP description has to be done. I have also
>> considered this possibility. Do you have any tangible proposal for how
>> such a mapping could be done, i.e. which elements to use ?
>>
>
> Well what I had in mind is the following:
> - first we need a clear definition of each verb. I think a registry of
> verbs is essential. But in general would be good to define some basic
> verbs that are likely to be needed anyway (share, view, etc.)
> - once you have a clear definition of verbs, you can do a mapping on
> existing equivalent services. For example, the view intent you defined
>
> action="http://webintents.org/view”
> type=“video/mp4v”
> href=“video-control.html“
> title = “Living room TV”
> disposition="window”
>
> could be mapped on the UPNP AVTransport service
> ("urn:upnp-org:serviceId:AVTransport") of a MediaRenderer.
> The "title" can be extracted from the device description (<friendlyName>
> tag in the device description)
> For the "href", that could be probably mapped on the presentation URL of
> the media renderer. This will require the device to be aware of this use
> case though, and also a way for the browser to know that the device
> presentation page is suitable for this. So maybe a better alternative is
> to slightly modify the AV transport service, adding this url either as
> part of the capability, or as return value of the play() method (or some
> other method).
>
> This needs more thoughts and if you start a document to describe
> intent-upnp mapping I'm sure me and other from the web&tv group will be
> interested in helping out.
>
>
>> Regarding same-origin constraints, could you elaborate a little on UA
>> "white-listing ?
>>
> i.e. if the user authorize app X communication with a service Y, the UA
> will add that device in a white list and allow comunication ebtween X and
> Y. This is part of our (opera/cablelabs) proposal
> http://people.opera.com/richt/release/specs/discovery/Overview.html#dfn-entry-script-origin-s-url-whitelist
>
>
> BTW not sure if it could be useful for you, but a while ago I've been
> playing with upnp communication over XHR and wrote some rough code
> http://upnpwidget.git.sourceforge.net/git/gitweb.cgi?p=upnpwidget/upnpwidget;a=blob;f=script/upnp.js;h=c602c5a17843116a5456e8f6dddeb3af0eacef33;hb=HEAD
>
> of course to make it work you need to bypass the same-origin constraints.
> One way of doing it is to run from file:// in Safari. Another is to run
> your application as a W3C widget in Opera.
> http://www.opera.com/widgets/
>
> Another sample implementation is this opera extension:
> https://addons.opera.com/en/addons/extensions/details/teletube/0.9.4/?display=en
>
> /g
>
>> Best regards
>>   Claes
>>
>> ________________________________________
>> From: Giuseppe Pascale [giuseppep@opera.com]
>> Sent: Tuesday, March 20, 2012 5:04 AM
>> To: Nilsson, Claes1
>> Subject: HN and Intents
>>
>> Hi,
>> interesting presentation. I have some comments but was difficult to take
>> them online so here you are:
>>
>> - I was wondering why you decided to extend UPnP and if you see a  
>> mapping
>> as a (possibly better) approach.
>> I think that being able to reuse existing HN devices AS IS is a major
>> benefit so we should aim for that if/when possible.
>>
>> Looking at your example, as far as the "view" verb is well defined, it
>> should be possible to define a standard mapping between services of any
>> kind (UPnP but not only) and the "view" verb. Since the whole thing is
>> mediated by the UA, that shouldn't be an issue, with the advantage of  
>> not
>> requiring changes to already deployed devices.
>>
>> To be clear: I think both a generic "discover"-based approach and a
>> "view"-based approach are valuable. But would be good to be able to use
>> the simple "view" intent with HN devices without having to fall back on
>> the complex UPnP communication clien side.
>>
>> - about using XHR for UPnP communication, the same-origin constraints  
>> can
>> be handled in 2 ways: UA white listing (this will require no changes to
>> the devices) or CORS (this will require device-side changes). Maybe you
>> may want to have both.
>>
>>
>>
>> /g
>>
>>
>>
>>
>> --
>> Giuseppe Pascale
>> TV & Connected Devices
>> Opera Software
>
>
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Wednesday, 21 March 2012 14:07:54 UTC