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

Nilsson, Claes1 wrote:
>>> 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.

The examples in [1] should be a good starting point:

http://people.opera.com/richt/release/specs/discovery/Overview.html#examples
>
> 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.

Assuming I can discover device services in the network via Web Intents, 
we'd need a way to whitelist a service's control point URL so that the 
page could then simply use existing APIs, such as XHR and Web Sockets to 
create and send direct messages to those device services. Sort of a 
'reverse-CORS' approach, where the user themselves choose the service 
they want to interact with and the UA allows XDM to happen only to 
declared control sub URLs. In [1] we solve this.

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


>
>>> 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.

Right but that doesn't work if the target device or service doesn't 
implement CORS, hence the proposal at [1] that allows us to support 
pre-existing devices and services...assuming existing devices and 
services will rarely, if ever, get OTA updates adding CORS support.

>>
>> [1] http://people.opera.com/richt/release/specs/discovery/Overview.html
>>

Received on Friday, 23 March 2012 07:32:33 UTC