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

Nilsson, Claes1 wrote:
> 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 . 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. 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.
>
> The "Light bulb" demo is implemented according the philosophy according
> to the 3^rd 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.

I don't think we would ever actively advocate for a proxy/plugin based 
solution on top of Web Intents here. There is a general assumption that 
this will require a proxy implemented either as a plugin or standalone 
proxy in order to take data communicated via Channel Messaging and 
convert it in to data packets that a UPnP device understands. When we 
start to lean on plugins we lose any  influence on good code quality, 
QA, patching issues or fixing bugs. That's proved to be an issue on the 
web of plugins and it's definitely not something we would actively 
promote as a core addition to the web platform.

I also have no faith that all UA implementations will support this Web 
Intents Extension natively or by default - leading any user to have to 
install extra things to make this work. That's not to mention the 
serious innovation restrictions this places around home-network based 
networking. If a device happens to speak JSON or ProtoBufs or the device 
is advertised via e.g. Bonjour rather than SSDP then I'm going to need 
more plugins and more patches to keep things going. A UPnP only solution 
only exposes a tiny fraction of the potential of the home network itself 
while catering only to UPnP-based device usage.

I'd be much more interested in implementing the primitives, the 
discovery protocols themselves, natively while allowing service 
messaging to happen without mandating any intermediate proxy or Web 
Intents Extension to handle the translation of Web Intents provided 
Channel Messaging Data to HTTP/Bluetooth/USB packets.

- Rich

>
> Best regards
>
>    Claes
>
> cid:3333625383_1036728
>
> *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.
>

Received on Thursday, 22 March 2012 00:40:05 UTC