Re: Discovery API proposals: call for comments

--------------------------------------------------
From: "Rich Tibbett" <richt@opera.com>
Sent: Wednesday, September 21, 2011 4:32 PM
To: "N.V.Balaji" <nv.balaji@samsung.com>
Cc: <public-device-apis@w3.org>
Subject: Re: Discovery API proposals: call for comments

> Hi,
>
> N.V.Balaji wrote:
>> Hi,
>> At a first glance it looks to me that Opera's proposal looks better as
>> it has a defined security model and integrates well with web messaging
>> specs. I should confess that I am not familiar with Webinos security
>> architecture. Moreover Opera's spec seems to leave the nitty-gritty of
>> client-server communication entirely to the service user and the
>> provider without requiring the UA to implement anything specifically.
>>
>> I have a couple of comments on Opera's specs. If these are discussed
>> already, pl. let me know as I might have missed previous discussions on
>> this topic.
>>
>> 1. I guess a notification API in NavigatorNetworkService would be very
>> valuable. The Notification API should announce newly discovered devices
>> - This API would enable interesting use cases. E.g. Assume a mobile user
>> entering into a room that has a TV. If The user entering a room can
>> figure out presence of a TV, the web page the user is currently viewing
>> can offer the user to play the same page on the TV. Actually this use
>> case is much more meaningful if the user is watching a video.
>> - To make sure that such a notification does not give away info
>> resulting in breach of privacy, the notification could be a plain one
>> informing the web page "there is something available" (without actually
>> providing type or NetworkService object), and the Web pages in turn can
>> invoke getNetworkServices to know the available service
>
> We actually envisioned this use case and the 'servicesAvailable' attribute 
> is for this purpose.
>
> To keep things as simple as possible we didn't include an event that fires 
> when other services of the same type add or leave the network. Having said 
> that, the following code, based on the current proposal with 
> servicesAvailable, would achieve the objective you describe above 
> (checking if new services have become available in the local network and 
> then offering the user to option to connect to them):
>
> <script>
> var servicesConnected = [];
>
> function getServices() {
>   navigator.getNetworkServices(
>     'urn:schemas-upnp-org:service:RenderingControl:1',
>     success
>   );
> }
>
> function success(servicesList) {
>     servicesConnected = servicesList;
>     pollForServiceAvailabilityChange(
>       servicesList[0].servicesAvailable
>     );
> }
>
> function pollForServiceAvailabilityChange(noOfServicesAvailable) {
>     setTimeout(function(){
>        if(noOfServicesAvailable <
>             servicesConnected[0].servicesAvailable) {
>          // re-request service auth since more services have
>          // since connected to the network
>          getServices();
>        } else {
>          pollForServiceAvailability(
>            servicesConnected[0].servicesAvailable
>          );
>        }
>    }, 5000);
> }
>
> getServices();
> </script>
>

[NVB]: The reason I suggested notification mechanism was to avoid polling 
:-) as Using polling mechanism is very inefficient.



>>
>> 2. As I understand the type to be used in getNetworkServices depends on
>> the external standards being used by the service provider. As a web
>> programmer, how do I detect a TV without knowing specific protocol being
>> used by the service provider. Am I supposed to invoke getNetworkServices
>> twice with different types?
>
> Currently, that is the expected behavior.
>
> We _could_ allow web pages to request more than one service type in the 
> getNetworkServices 'type' argument. So you could request multiple service 
> types from the network. In the NetworkService result we would echo the 
> service type that the user selected in a 'type' attribute.
>
> Something like the follows:
>
> navigator.getNetworkServices(['_boxee-jsonrpc._tcp', 
> '_xbmc-jsonrpc._tcp'], success);
>
> function success( services ) {
>   for(var i in services) {
>     var serviceType = services[i].type;
>     if(serviceType == '_boxee-jsonrpc._tcp') {
>       // communicate with Boxee's JSON-RPC API via services[i].url
>     } else {
>       // communicate with XBMC's JSON-RPC API via services[i].url
>     }
>   }
> }
>

[NVB]: This works given that we have only 2 discovery protocols.



> Sound good?
>
> - Rich
>
>>
>> -
>> Balaji N V
>> Samsung
>>
>>
>>
>>
>>
>> --------------------------------------------------
>> From: "Robin Berjon" <robin@berjon.com>
>> Sent: Tuesday, September 20, 2011 1:27 PM
>> To: <public-device-apis@w3.org>
>> Cc: <public-web-and-tv@w3.org>; "W3C WebApps WG" <public-webapps@w3.org>
>> Subject: Discovery API proposals: call for comments
>>
>>> Hi all,
>>>
>>> there have been two primary proposals for a Discovery API that would
>>> enable web pages to (shockingly enough) discover services (on the
>>> device, the local network, or possibly remote) through common
>>> mechanisms such as DNS-SD or UPnP.
>>>
>>> One of them comes from Opera:
>>>
>>> http://people.opera.com/richt/release/specs/discovery/Overview.html
>>>
>>> And the other comes from Webinos:
>>>
>>>
>>> http://dev.webinos.org/deliverables/wp3/Deliverable32/static$42d2e5ab28271945244cdeb7579c65fd.html
>>>
>>>
>>> Ideally, we'd like to start with either of those and, if sensible,
>>> make sure it supports the use cases of the other. We're therefore
>>> calling for feedback from anyone interested in this topic.
>>>
>>> Please direct replies towards public-device-apis@w3.org where the work
>>> is taking place. Thanks!
>>>
>>> --
>>> Robin Berjon - http://berjon.com/ - @robinberjon
>>>
>>>

Received on Wednesday, 21 September 2011 13:19:12 UTC