Re: [discovery-api] Draft spec updates

A couple of questions.

1.
How are onserviceavailable/onserviceunavailable on NetworkServices
different from onserviceonline/onserviceoffline on the NetworkService
objects themselves? It'd be nice to get rid of "NetworkServices" and
just return an array of "NetworkService".

Also, shouldn't the interaction with the service URLs themselves
provide these signals? That is, if I have the url, shouldn't this
online/offline available/unavailable status be reachable by using
messaging APIs directly with the url? If there out-of-band channels by
which the UA can receive availability information, wouldn't it be
better to have the UA inject that information into the messaging API
directly? For example, if the client does new
EventSource(service.url), then availability information would be
reflected in the readyState of EventSource, and notified through its
eventing mechanism.

2.
What purpose does the id of the returned service have? I see
NetworkServices can get a service by ID, but wouldn't I have to
iterate through the array and read the IDs anyway? Is this useful when
using the url? I don't see the utility of the getServiceById API.

In a similar vein, what purpose does the returned |config| have? Is
this just extra data the service is telling the client, which may be
helpful in navigating the control protocol?

I can see why it is nice for the client to have a user-friendly name
-- it can be used to indicate to the user the device they are
interacting with.

3.
The user verification steps are good as a semantic point, I think, but
the spec seems too insistent that the user be prompted for every
discovery interaction. If they have a TV they are controlling, why not
enable that to be used by default? I think the thinking from comparing
web intents and registerProtocolHandler will prevail -- the set of
APIs that allow users to select handlers, services, etc. will be
presented to the user in a uniform way by UAs, and so the same
defaulting policies should apply to all.

---

It looks to me like the only additional ingredient here above what
could be provided by a web intents-based "discover" intent is to add
the returned urls to the cross-site accept list. That's obviously an
important ingredient, but I don't think that's a big obstacle for
using web intents for url discovery. We've done a similar
implementation in Chromium for passing Filesystem objects through
intents -- they need to be special-cased to provide the right sandbox
permissions. Special-casing a hypothetical "discover" action type
would be about the same code path.

It looks to me like this method of connecting clients to service urls
differs in character to the work Claes &co are doing with the UPnP
web-intents-based service discovery addendum [1] in that this supposes
the client will understand how to use the returned url "natively" (or
perhaps when given a config string for guidance), whereas the addendum
allows for higher-level controls, like "view", which pass control
directly to the equipment. But couldn't we augment the addendum with
something like:

startActivity({"action": "discover", "type": typelist},
function(services) { attachToService(services[0]); });

to provide for direct control url discovery? This looks like a pretty
direct translation, and would get presented to the user in essentially
the same manner. This mechanism has the advantage of being able to
interoperate with non-local services as well -- discovering an
endpoint url that controls a remote videoconference camera, for
instance, or a tele-operated piece of equipment.

[1] http://w3c-test.org/dap/wi-addendum-local-services/



On Tue, Sep 25, 2012 at 4:42 AM, Rich Tibbett <richt@opera.com> wrote:
> A new version of the Networking and Service Discovery & Messaging
> specification is now available as an ED update.
>
> This update incorporates all of the (excellent) feedback previously
> submitted to this list by Cathy [1] [2]. The net result is a major rewrite
> and clarification of the underlying rules and algorithms included in the
> draft specification. This update does not affect the operation of the API
> interfaces previously included but is instead more targeted at clarifying
> low-level implementation details of working with different network discovery
> protocols.
>
> The latest draft of this specification is available in the usual place:
>
> http://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
>
> Any further feedback you have would be very helpful in moving this
> specification forward.
>
> Best regards,
>
> Rich
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2012Aug/0017.html
>
> [2] http://lists.w3.org/Archives/Public/public-device-apis/2012Aug/0095.html
>

Received on Wednesday, 26 September 2012 16:21:46 UTC