Re: Discovery API proposals: call for comments

On 22/09/11 23:07, 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.
>
> - Cathy.

+1

The getNetworkServices call surprised me by only reporting services the 
browser had already found prior to that call. I had expected the call 
back to be invoked whenever a matching service appears or disappears. To 
stop such call backs you would call getNetworkedServices again with NULL 
for the call back function. The first call back would be quick and would 
provide the list of matching services that the browser already knows about.

I would also like to see a more generalized discovery and messaging 
mechanism that isn't limited to HTTP.  Why can't we allow web 
applications to discover and use services on devices connected by other 
interconnect technologies, e.g. USB, Bluetooth, Firewire, NFC and ZigBee?

As an example involving NFC, imagine using a web application in your 
phone to display information about an object with an RFID tag, or to 
exchange information with someone by touching your phone to theirs, or 
to sign in to a website or to pay for an online purchase, by touching 
your phone to your notebook computer.

Instead of providing a URL to access the service as with the 
getNetworkedServices proposal, the service object directly exposes the 
interface for accessing the service.  It is also worth distinguishing 
discovery and binding, as users may want to view information about 
services before selecting which one to use.  This is a feature of the 
webinos API where you call the bind method on the discovered service to 
bind it.

Here is a typical scenario:

1. web page call findServices with service type and found, lost and 
error call backs

2. web page displays list of matching services where the list is 
dynamically updated via found and lost callbacks.

3. user selects a service

4. web page calls bind method on service passing it a object with 
handlers for bound notification etc.

5. web page makes use of the bound service via methods and properties 
exposed by service object

The user is asked for permission for the web page (or installed web 
widget) to:

    a.   access to service descriptions (as passed with found callback)
    b.   bind to a service and make use of it

The ability for web page scripts to scan your local environment is a 
risk to your privacy, and as such this must be subject to user control. 
Knowing about a service and being able to use it are two different 
things. This makes in necessary for users to further control which 
services a web page can bind to. Ensuring usability of such control is a 
challenge and should be beyond the scope of the discovery specification, 
although we should certainly be free to discuss what we feel to be good 
practices.

Note that an alternative to the above would be to hand the task of 
presenting the list of services and binding to a service selected by the 
user over to the browser.  The web page script would in essence be 
limited to seeding the search parameters and requesting the browser to 
ask the user to make a choice.

1. web page calls getService with service type and success/failure callbacks

2. getService returns immediately with a handle that can be used to 
remove the selection UI

3. browser displays the service selection UI with a dynamically updated 
list of services

4. user clicks on chosen service or on cancel button

5. web page call back invoked with service object with bound interface 
for that service

In this approach the web page doesn't get to scan the local environment 
which is a plus for privacy, but a negative for some kinds of 
applications that want to offer functionality based upon a knowledge of 
what devices/services are available.

The selection UI could be enhanced to allow the user to assign and 
search on tags for each service, in the same way that you can use tags 
for photo's on flickr.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Friday, 23 September 2011 10:23:59 UTC