Re: Discovery API proposals: call for comments

--------------------------------------------------
From: "Dave Raggett" <dsr@w3.org>
Sent: Friday, September 23, 2011 3:53 PM
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.




[NVB]: That would mean that the interface JavaScript API should be defined 
for each service type.  Pl. correct me if I am wrong.  Given the enormity of 
this task (of defining APIs that can work over multiple protocols and
implementing them) it is better that we go for a simpler approach, even if 
it is narrower in scope.





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.



[NVB]: Could you please share a use case that benefits from the knowledge of 
what services available to a page. IMHO, the available services should be 
provided to the web page only upon user granting the permission
 - the ability of web page to scan the local environment should be subject 
to user permission, as you have pointed out rightly in the previous 
paragraph.




>
> 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 Monday, 26 September 2011 06:58:42 UTC