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>

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

Sound good?

- Rich

>
> -
> Balaji N V
> Samsung
>
>
>
>
>
> --------------------------------------------------
> From: "Robin Berjon" <robin@berjon.com>
> Sent: Tuesday, September 20, 2011 1:27 PM
> To: <public-device-apis@w3.org>
> Cc: <public-web-and-tv@w3.org>; "W3C WebApps WG" <public-webapps@w3.org>
> Subject: Discovery API proposals: call for comments
>
>> Hi all,
>>
>> there have been two primary proposals for a Discovery API that would
>> enable web pages to (shockingly enough) discover services (on the
>> device, the local network, or possibly remote) through common
>> mechanisms such as DNS-SD or UPnP.
>>
>> One of them comes from Opera:
>>
>> http://people.opera.com/richt/release/specs/discovery/Overview.html
>>
>> And the other comes from Webinos:
>>
>>
>> http://dev.webinos.org/deliverables/wp3/Deliverable32/static$42d2e5ab28271945244cdeb7579c65fd.html
>>
>>
>> Ideally, we'd like to start with either of those and, if sensible,
>> make sure it supports the use cases of the other. We're therefore
>> calling for feedback from anyone interested in this topic.
>>
>> Please direct replies towards public-device-apis@w3.org where the work
>> is taking place. Thanks!
>>
>> --
>> Robin Berjon - http://berjon.com/ - @robinberjon
>>
>>

Received on Wednesday, 21 September 2011 11:02:58 UTC