Re: Discovery API proposals: call for comments

--------------------------------------------------
From: "Giuseppe Pascale" <giuseppep@opera.com>
Sent: Saturday, September 24, 2011 1:46 PM
To: <Cathy.Chan@nokia.com>; "Rich Tibbett" <richt@opera.com>
Cc: <public-device-apis@w3.org>
Subject: 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.

[NVB]: This seems to be an interesting idea.  But typical semantics of a 
success callback is to get invoked only once - Isnt't it?


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

[NVB]:  is it not possible with the existing spec ?

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


[NVB]: This interface, if present, should be part of NavigatorNetworkService 
and NOT NetworkService


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


[NVB]: As far as my understanding goes, onreadystatechange would have got 
fired when the service became unavailable and getNetworkServices would NOT 
return this object (based on the Algo specified in section 4.11)

Thinking about the re-invocation of getNetworkServices, I have couple of 
more questions:

1. should we remove the service from the whitelist, if it leaves the 
network?
2. If all services that are available are found to be in the whitelist, 
should step 10 (prompting the user for access grant) be invoked again? IMO, 
user should be prompted only for services that are not part of the whitelist





>
> /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 Monday, 26 September 2011 06:11:08 UTC