RE: Discovery API proposals: call for comments

Hi, 

Regrets for being quiet on this matter since I posted information on the Webinos Service Discovery API but I have been forced to focus on other urgent matters for the latest weeks. Anyway, getting back on track in DAP now.

Thanks for your input Dave.

We must get a structured view on the similarities and the differences between the Opera/CableLabs service discovery proposal (http://people.opera.com/richt/release/specs/discovery/Overview.html#dom-networkservice-type) and the Webinos service discovery proposal (http://dev.webinos.org/specifications/draft/servicediscovery.html). Some of the differences are mentioned in the mail below by David and I would like to further elaborate on this.

It seems as the design goals of the two proposals were somewhat different.

For the Webinos proposal the original problem was defined as:

------------------------------------
"How to provide a consistent way for web applications to access user's resources or any other resources hosted anywhere, i.e. in user's current device, in another device connected through the network, at a network server, or in a locally connected device.

The problem has two major parts:
    Service Discovery
    Access to the service"
------------------------------------

This lead to an API that has a high level of abstraction and the API itself is agnostic to lower level discovery and communication methods. It seems to me as the scope of the Opera/CableLabs proposal is narrower as it only supports local-networked Services provided over HTTP.

In Webinos a service type is defined by it's JavaScript API. For example the W3C Geolocation API (see example in http://dev.webinos.org/specifications/draft/servicediscovery.html ) or the Webinos Sensor API (see example in http://dev.webinos.org/specifications/draft/sensors.html ).

Below Dave describes the process of discovery and binding (access to the service selected by the user through a JavaScript API) so I don't have to repeat that. I can just add that there is a filter function that could be used to narrow the search to for example only locally connected devices, to specific locations of devices or to a specific user's devices ("Personal Zone" in Webinos context). This concept is different from the Opera/CableLabs proposal where the service type instead is a service type token related to the underlying service discovery mechanism (UPnP or Zeroconf) and communication with the discovered service is performed through any existing messaging api such as XMLHttpRequest, Web Sockets or Web Messaging.

As David also says I can't see the reason why we shouldn't provide a discovery mechanisms that isn't limited to HTTP but instead applicable for any underlying low level discovery and communication mechanism. We should create a reasonable easy to use API for Web developers that hides underlying details. Of course, the lower layer discovery and communication mechanism have to be solved but are they subject for further standardization in addition to the standards that already exist?

I hope to come back soon with a more structured and detailed comparison between the two proposals.

Best regards
  Claes
 
> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Dave Raggett
> Sent: den 23 september 2011 12:24
> To: Cathy.Chan@nokia.com
> Cc: public-device-apis@w3.org
> Subject: 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 15:38:08 UTC