Re: Discovery API proposals: call for comments

Hi Rich,

Thanks for the swift reply. Some follow up questions below.

On 22/09/11 12:48, Rich Tibbett wrote:
>
>> 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.

I see that working for discovery protocols where services are 
periodically advertised, e.g. on a multicast port. However, such 
protocols also allow you to make a search probe on a given service type, 
and avoids waiting for the next periodic advertisement, which could take 
a while.

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

I understand the capability to name a specific service on a specific 
device with the appropriate agreements on how to encode the device name 
somehow as part of the service type string. Wouldn't it be more flexible 
to allow such data to be separated out in a JSON valued parameter?


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

The idea of a filter is to only show choices that are relevant rather 
than burden users with ones irrelevant to the current context.

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

It would certainly be preferable to avoid burdening the user in 
permissions UI which suggests a spec level behavior.


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

Hmm, why single out HTTP in this way, given the widespread availability 
and continuing evolution of other interconnect technologies (e.g. USB, 
Bluetooth, Firewire, NFC, ZigBee)?   In what way is HTTP required by the 
interfaces in the current proposal?

A further question. How do you send a message to a discovered network 
service?  The corresponding interface includes the DOM EventTarget 
interface, so I am guessing that you can target an event at the object 
for the network service. This seems a little at odds with the "event 
handler attributes" defined as functions that can be set. Why didn't you 
either stick with DOM events for both notifications and targeting 
events, or instead, stick with functions, and define a method for 
sending a message to a service?

Many thanks,

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

Received on Thursday, 22 September 2011 12:37:33 UTC