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: Dave Raggett <dsr@w3.org>
Date: Fri, 23 Mar 2012 08:06:35 +0000
Message-ID: <4F6C2F0B.3090200@w3.org>
To: Rich Tibbett <richt@opera.com>
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>
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.

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.

-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Friday, 23 March 2012 08:07:08 UTC

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