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:23 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:29 GMT