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

Our implementation is not limited by HTTP, either.

-Clarke

On 3/23/12 3:01 PM, "Bob Lund" <B.Lund@CableLabs.com> wrote:

>
>
>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.htm
>>>>l
>>>
>>> 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 20:26:21 UTC