Re: Discovery API proposals: call for comments

On Fri, 23 Sep 2011 02:40:42 -0700, Rich Tibbett <richt@opera.com> wrote:

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

I also have a mild preference for some notification when new services are
available.

I have 2 options in mind (with a preference for option #1):

#1
Have the successCallback to be called each time there is an update.
If we want to go that way and still allow the user to control what is  
exposed we could change the behaviour of such callback as follows:
- an application interested in the service type X calls getNetworkServices  
for the service X.
- the user agent require the user to autorize which services should be  
exposed (with a UA defined mechanisms like dialogs or other)
- the application get a success callback with the list of services  
authorized by the user.
- when new services are available **the UA** notifiy the user about the  
new services and ask if he want to expose also the new one to the  
application
- if the user accept, the successCallback is called once again with the  
update list.

Such a solution would address also another usecase:
you may be in a situation where your services are always available (from a  
network point of view), but the user may start authorizing only (say) 1  
(so that is returned by getNetworkServices); later the user (via a UA  
menu) decide to authorize access to more services. This, from the  
application point of view, should be threated as a "new service available"  
even though the service has always been available.


#2
Additional event in addition to onmessage and onreadystatechange.  
something like onmoreservicesavailable (name is just an example).
The only concern I have with this approach is if having this event (and  
actually also the ServicesAvailable attribute) as an attribute of one  
specific service object is appropriate.


On a different topic, one more question: what should happen if the  
following happens
1) a service leave the network (e.g. UPnP bye bye)
2) you call getNetworkServices. Should the callback still return the  
service with readyState set to unavailable or should the callback do not  
return that service?

/g

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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Saturday, 24 September 2011 08:17:21 UTC