Re: Discovery API proposals: call for comments

On Mon, 26 Sep 2011 08:10:30 +0200, N.V.Balaji <nv.balaji@samsung.com>  
wrote:
>>
>> 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?
>

indeed, so if we go this way we may want to change the architecture a  
little bit,
maybe having something similar to XHR, i.e.  
getNetworkServices/onnetworkservicesavailable as similar to  
send/onreadystatechange.

What do you think?


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

Possible but not clear I would say. Basically depends from how the user  
agent implements it, since ultimately is the UA that notify the  
application about new services.
This is one of the key point of the proposal: the UA control discovery, so  
we are not doing a 1:1 mapping with the underling discovery protocol (for  
security reasons).

We may want to emphasize this in some informative text; Rich, what do you  
think?


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

yep, so basically my proposal would be to merge my point #1 and #2 as  
explained above.

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

This is an option, but we should consider (thinking aloud here) if we want  
to go for a model where a device may be returned even if "unavailable".
In such a model the UA would be responsible for deciding when a device is  
"gone" (and should be removed by such a list) and when is still worth  
keeping it in the list as "unavailable". Use cases I have in mind here are  
2:
* the UA may want to be robust against short cycles of  
available/unavailable/available (for whatever reasons they happen)
* there could be devices that even though unavailable could be waken up  
(e.g. via Wake-on-lan). Of course support for this would require some more  
details to be specified, but if the overall architecture support it we can  
extend it to support such protocols.


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

Good question, I'm not sure there is a good answer though. If we remove  
it, and ask the user to accept it again once he comes back to life, I see  
2 main issues:
1. poor user experience if for some reason the device goes on and off  
frequently (standby?)
2. some user may want to configure their network whitelist once and not  
having to approve these devices everytime. As we discussed in the web&tv  
IG, this may be particularly handy for elder people or people with  
disabilities that may ask someone else to configure their setup.

Anyway, since this security mechanism is controlled by the user agent, I  
think the ultimate decision should be left to the UA. I would say the UA  
may remove that device from the whitelist, but the UA may also enable the  
user to manually configure a list of devices that an application is  
allowed to access, so that each time that application is used it  
automatically gets access to those devices.

Does this sound fine or are there concern about this approach?


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

agree. as mentioned before, we should also discuss if the UA may have a  
static setting of which devices are authorized so that it does not need to  
ask the user each time.


/g


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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 26 September 2011 12:40:44 UTC