W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

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

From: Rich Tibbett <richt@opera.com>
Date: Fri, 23 Mar 2012 16:42:01 +0800
Message-ID: <4F6C3759.4010206@opera.com>
To: Dave Raggett <dsr@w3.org>
CC: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, Giuseppe Pascale <giuseppep@opera.com>, "public-web-intents@w3.org" <public-web-intents@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "Isberg, Anders" <Anders.Isberg@sonymobile.com>, "Edenbrandt, Anders" <Anders.Edenbrandt@sonymobile.com>, "Ekberg, Björn" <Bjorn.Ekberg@sonymobile.com>
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.

> 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 08:42:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC