Re: Web Intents for local network services - Clarification on browser UPnP support

On 3/23/12 2:42 AM, "Rich Tibbett" <richt@opera.com> wrote:

>Dave Raggett wrote:
>> On 23/03/12 07:31, Rich Tibbett wrote:
>>> Hiding or gatewaying the device service message from behind Web
>>> Intents is going to lead to the plugins approach I discussed in my
>>> previous email:
>>>
>>> 
>>>http://lists.w3.org/Archives/Public/public-web-intents/2012Mar/0056.html
>>
>> Another possibility would be to put the code for communicating with the
>> device/service into a browser extension/add on. This code would
>> implement one end of a message channel where the other end is exposed to
>> the web page script via web intents.
>
>Well this would work but is still requires an Extension to proxy stuff.
>As a developer you couldn't rely on that being available when you're
>writing your web page.

FYI. At CableLabs we implemented [1] that exposes UPnP and Zeroconf
discovery. We also implemented a demo Web app that use both UPnP CDS, CMS
and AVC as well as Bonjour DAAP (all implemented in JS) for accessing
content using the API. Our implementation experience suggests that the
level of abstraction exposed by the UA in [1] is a good level: those
things that cannot be done by script are done in the UA, the UA mechanism
is general enough to span multiple HN protocols and implementing home
network services as Web apps works well.

Bob Lund


>
>>
>> To avoid the need for a plugin, the extension script would need access
>> to a socket API for the discovery part. This approach enables the
>> extension to implement a device abstraction layer where the web page
>> script is independent of whether the device is connected via Zero conf,
>> UPnP, or other mechanisms including Bluetooth and USB.
>>
>> A further possibility is to just use web intents for discovery, and then
>> have a script library loaded by the web page itself to implement the
>> abstraction layer. This would work for UPnP where the device protocol is
>> HTTP, but not for other cases where the protocol isn't HTTP.
>>
>
>I'd be happy to limit the scope of this interaction to HTTP based
>services initially. I think we would need some abstraction mechanisms
>for e.g. Bluetooth or USB communication and I'd be happy to tackle those
>as part of a different API.
>
>- Rich
>

Received on Friday, 23 March 2012 19:02:41 UTC