- From: Dave Raggett <dsr@w3.org>
- Date: Fri, 23 Mar 2012 08:06:35 +0000
- 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:10 UTC