Re: Discovery API proposals: call for comments

Cathy.Chan@nokia.com wrote:
> +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.

Hmm. In this case you would receive a readystatechange event indicating 
that the current NetworkService has disconnected. If servicesAvailable 
remains constant then you now have a different service available in its 
place.

Regardless, I do agree there may be some scope for improvement in this 
area. We want to retain the user's privacy as much as possible here (so 
pages cannot profile the user's network of devices and services, for 
example). There are naturally other models we could use but we just need 
to decide which one gives us the most benefit with the least privacy 
leakage.

- Rich

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

Received on Friday, 23 September 2011 09:41:07 UTC