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

See inline below.

 Claes

> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: den 21 mars 2012 10:58
> To: public-web-intents@w3.org; public-device-apis@w3.org; Nilsson,
> Claes1
> Cc: Isberg, Anders; Edenbrandt, Anders; Ekberg, Björn
> Subject: Re: Web Intents for local network services - Clarification on
> browser UPnP support
> 
> On Wed, 21 Mar 2012 08:59:37 +0100, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
> 
> > Hi,
> >
> Hi, since I'm not at the meeting allow me to ask few questions
> 
> > Based on the questions I got related to the presentation (
> > http://www.w3.org/wiki/WebIntents/SonyMobile_-

> _Local_Network_Service_Discovery
> > ) and demo ("Light bulb discovery and control) that I showed at the
> > ongoing Shenzhen meeting I would like to clarify how I envision the
> > browser's UPnP support should look like.
> >
> > The "Light bulb" demo was run in the Chrome browser and we use a upnp
> > plugin that provides a JS API.
> 
> When you say "plugin" you mean a NPAPI plugin?


It is an experimental API implemented as a windows dll installable with regsvr32.

> 
> > We are also experimenting with a similar API for the Android browser.
> > This API provides a UPnP/SSDP search method with three parameters,
> > service type, success callback and error callback.The success
> callback
> > is invoked for each UPnP/SSDP service discovered or lost and all
> > contains the received SSDP M-Search response headers. From the
> LOCATION
> > header the Device/Service description document could be retrieved.
> 
> How does this differ form the API proposed in [1] ?

We discussed [1] at the meeting today. I need to read this specification carefully but my impression is that it probably provides something similar (and more!) to our simple, experimental API. We call this API from our version of the JS shim's Web Intents picker. My initial view is that it would be possible to use your API instead in this JS Web Intents picker. 

If we want to be able to use Web Intents for local network service discovery could your API to be a component within the UA's implementation of the Web Intents support for local network Services? I am interested in your and Richard's view on this.

> 
> > Subsequent control communication with the service device is then
> > performed by the Web Intents Client page or Service page (depending
> on
> > UX and Service implementation solution used) through xhr or web
> sockets.
> >
> So, is the Service Page fetched from a web server on the actual device
> (or
> a proxy on the network)? Or is something generated by the browser?

In this simple demo the Service page is fetched from local host. 
> 
> /g
> 
> > The "Light bulb" demo is implemented according the philosophy
> according
> > to the 3rd option in my presentation, i.e. the Client page talks over
> > postMessage with simple JSON commands, "toggle on/of", to the Service
> > Page, which then sends UPnP commands to the "Light bulb" device.
> >
> 
> 
> [1] http://people.opera.com/richt/release/specs/discovery/Overview.html

> 
> > Best regards
> >   Claes
> >
> > [cid:image001.gif@01CD0723.6D9A9730]
> >
> > Claes Nilsson M.Sc.E.E
> > Master Engineer, Research
> > Technology Research - Advanced Application Lab
> >
> > Sony Mobile Communications
> >  Phone:  +46 10 80 15178
> > Mobile: +46 705 56 68 78
> > Switchboard: +46 10 80 00000
> > E-Mail:
> >
> mailto:claes1.nilsson@sonymobile.com<mailto:claes1.nilsson@sonyericsson
> .com>
> > Visiting Address; Nya Vattentornet
> > SE-221 88 LUND,
> > Sweden
> > Disclaimer:
> > The information in this e-mail is confidential and may be legally
> > privileged. It is intended solely for the named recipient(s) and
> access
> > to this e-mail by anyone else is unauthorized. The views are those of
> > the sender and not necessarily the views of Sony Ericsson and Sony
> > Ericsson accepts responsibility or liability whatsoever or howsoever
> > arising in connection with this e-mail.Any attachment(s) to this
> message
> > has been checked for viruses, but please rely on your own virus
> checker
> > and procedures. If you contact us by e-mail, we will store your name
> and
> > address to facilitate communications. If you are not the intended
> > recipient, please inform the sender by replying this transmission and
> > delete the e-mail and any copies of it without disclosing it.
> >
> >
> 
> 
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software

Received on Thursday, 22 March 2012 06:55:40 UTC