RE: Discovery API proposals: call for comments

+1 on avoiding polling.

Not to mention that using the number of services alone to detect changes in 
available services is simply unreliable. What if I started with two rendering 
control services, one of them left the network while a brand new one joined 
the network during a polling interval? The number of services would be the 
same, but the actual services would be different.

- Cathy.


N.V.Balaji wrote:

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