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

Hi Rich and Bob,

In the presentation http://www.w3.org/wiki/images/f/fa/W3C_Web_Intents_-_Local_Service_Discovery.pdf I describe different options for allowing Web Applications discover and interact with not only cloud Services, but also local network Services. As there is a momentum for Web Intents the assumption in this presentation is that this concept should be used. The basic idea is that we should have a consistent service discovery model, i.e. Web Intents, for web applications. This could make it possible to write web applications that requires an Action that could be executed by a Web Intents Service situated "anywhere". The Client web application does not have to know whether the executing Service is local or remote or whatever. 

To support Web Intents Services located in a local, UPnP in my example, networks I show three different ways to solve this. I don't say that these are the only alternatives, there are probably more ways to do this.

Responses to your comments:

* I am not sure that I understand your view that Web Intents based discovery is a "proxy/plugin"-based solution. If so, are all Web Intents Services proxies? 
* The idea with the solution proposal on page 21 in the presentation is that the Client application should not have to be aware of any low level discovery protocols such as UPnP and Bonjour etc and that it talks, over channel messaging, to the Service through a high level protocol. This would work even when the Service is on a cloud server.
* The other two implementation proposals does not assume channel messaging with the Service. The proposal starting at page 16 is quite similar to your approach including the disadvantage that the Client page has to be implemented according to the control communication specific to the discovered device. However, existing UPnP devices could be discovered and controlled by this approach.
* Browser support for UPnP/SSDP discovery is needed and the cross-domain issue has to be solved. One option is white-listing URL's according to your proposal. 
* Regarding your comment " I also have no faith that all UA implementations will support this Web Intents Extension natively or by default" I don't see the difference with your proposal. Any API for allowing Web Applications discover local network services requires the UA to support low level discovery protocols, UPnP, Bonjour etc. This is not different in a Web Intents based solution from a solution based on your API proposal.

Best regards
  Claes

> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: den 23 mars 2012 09:42
> To: Dave Raggett
> Cc: Nilsson, Claes1; Giuseppe Pascale; public-web-intents@w3.org;
> public-device-apis@w3.org; Isberg, Anders; Edenbrandt, Anders; Ekberg,
> Björn
> Subject: Re: Web Intents for local network services - Clarification on
> browser UPnP support
> 
> 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 Tuesday, 27 March 2012 13:29:13 UTC