Re: Discovery API proposals: call for comments

Hi Dave,

Dave Raggett wrote:
> Some clarification questions about:
>
> http://people.opera.com/richt/release/specs/discovery/Overview.html
>
> Reading the algorithm, it seems that getNetworkedServices is supposed to
> return quickly with a list of network services objects matching the
> given service type name.

See step 12 in 
http://people.opera.com/richt/release/specs/discovery/Overview.html#dom-navigator-getnetworkservices.

> If no services have been found in this time a
> task is queued to invoke the error call back (if supplied) and
> getNetworkedServices then returns.

See step 9 in 
http://people.opera.com/richt/release/specs/discovery/Overview.html#dom-navigator-getnetworkservices

>
> In many cases, local discovery protocols take time to take effect. Is
> the browser supposed to have discovered services in advance so that a
> match can be made immediately?

That is the proposal, yes. I'll note at this point that the Opera 
Desktop browser already does this. If a user enables 'Opera Unite' (in 
the status bar) then the browser finds other Opera Unite devices as a 
background operation. The overall performance effect of performing this 
discovery process in the background is currently nil.

> That doesn't seem likely although it is a
> possibility, e.g. with mDNS where the avahi daemon listens on a
> multicast port and maintains a cache. Even so, what I connect (or turn
> on) my device *after* the script calls getNetworkedServices?

Then the device will not be available for the user to select and an 
additional call to getNetworkServices must be made. The UI for how you 
do that is entirely up to the web page.

>
> Perhaps I am misreading the algorithm. I would have expected it to take
> up to a few seconds for a success call back, judging from my experience
> with writing a discovery plugin for mDNS, SSDP, SLP, Bluetooth and USB.
> One challenge is when to ask users for permission to grant access to
> each of the matching services. I would expect to give browsers some
> freedom in how they deal with that.

As mentioned above, this is defined in step 12 of 
http://people.opera.com/richt/release/specs/discovery/Overview.html#dom-navigator-getnetworkservices.

>
> What about being able to filter services by context, e.g. by friendly
> name, location, by ownership (Pete's phone), or other properties? Users
> may for example want to type a user friendly name for a device/service
> into a search box.

The proposal definitely does not connect web pages to a very specific 
device or very specific service. Instead we have the abstract concept 
target service types. Any device that implements a requested service 
type is treated as an equal candidate for connection via this API.

We're promoting device and service neutrality - letting the little guys 
play with the big guys - by using service type tokens instead of the 
ability to target specific services running on specific devices.

> Multicast DNS is nice in that regards, as it allows
> users to assign names that can encapsulate the owner, the location and
> the service. It would be nice to allow for smarter search where these
> properties are separated out (what services are available in my living
> room), and a JSON valued argument would be more flexible than a single
> DOM string for a valid type name.

I'm not really sure on this point. If as a user I'm presented with a 
list of 5 devices that are capable of handling the requested service 
type then I'm sure I'd be able to pick out the one in my living room if 
I so wished.

>
> My samsung printer supports mDNS,, SSDP and SLP. Am I correct in
> thinking that getNetworkedServices will provide different network
> service objects for the same service, when exposed by different
> discovery protocols?

Duplicates could be resolved at the user interface level or we could 
define such de-dup behavior in the spec.

>
> Does getNetworkedServices also apply to other kinds of interconnect
> technologies such as USB, or services directly coupled to the device
> hosting the web run time? This suggests changing the terminology to be
> more general, e.g. findService.
>

This proposal allows discovery and connection to _HTTP_ service 
endpoints only. Bluetooth and USB would be nice but we decided not to 
overload this API beyond its intended capability.

- Rich

Received on Thursday, 22 September 2011 11:48:55 UTC