Re: [discovery-api] Draft spec updates

Thanks, Rich.

On Thu, Sep 27, 2012 at 12:24 AM, Rich Tibbett <richt@opera.com> wrote:

[service availability events]

> It just so happens that we also get cues about a service's availability from
> the network service discovery protocols themselves so we also expose these
> in this API. The general premise for this is that if, as a web developer,
> I've been informed that a service is offline (because its advertisement
> expired, the service gracefully left the network or the user dropped or
> changed networks) then I don't have to block my in-page UI and rely on
> waiting for a URL request to timeout via the XHR, Web Sockets or Server-sent
> events APIs to know that fact (...though you could if you really wanted to
> by just ignoring the discovery protocol availability cues and querying the
> URL regardless of the cues provided).

If the client has the url open through some messaging protocol, those
cues can just be signaled through that channels own events. If it
doesn't, isn't what the client really wants is events about joining
and leaving the network of particular devices? But I don't see how
that meshes with the user consent parameters. That is, it sounds like
I can bypass the consent provisions by simply issuing the call, then
plugging in a matching device, which then gets notified. I guess my
mental model is that a user dissatisfied with what they see as the
service options will fiddle with their network (or perhaps just try
repeatedly :-)) until they either give up or see what they hope to
see. At that point, they hand the client the url and go on. The spec
seems to me to want the UA to keep the list of available attached
devices, not to enable web content to be an indicator of those
devices. If this latter is a use case, that, it seems to me, would be
a different privacy regime where you'd want an API like

EventTarget RegisterForLocalNetworkServiceNotifications();

and then you can attach to those services based on the events
delivered to you, perhaps with a separate set of permissions.

[id]

>
> The use case is where I've previously obtained a set of NetworkService
> objects via getNetworkServices and I've now re-requested a new set of
> services via the same API. The second set of NetworkService objects is not
> necessarily ordered in the same way as the first set and may or may not
> contain some or all of the same set of objects from the first request.

It seems to me that the client at that point can just traverse the set
and establish identity with any ongoing sessions itself. If the IDs
are part of the device identity, then the url ought to be the same,
right?

>
> getServiceById was a way to quickly lookup if a service obtained in the
> first lookup is still present in the second lookup.
>
> Admittedly though, getServiceById is not one of the 80% use cases and could
> be achieved by iterating through the services returned in the second success
> callback and matching up the services from there. IIRC, we were trying to
> maintain feature parity here with other similar HTML APIs e.g.
> [Audio|Video]TrackList:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#audiotracklist-and-videotracklist-objects

These tracklists look to me more like they're about specific media
objects with multiple components (i.e. a slideshow or video with
multiple parts).

[config]

> Yes. Mostly it's meta information about the device associated with the
> current NetworkService. That's typically things like friendlyName, make,
> model, unique device identifier, etc (Device descriptor document <device>
> elements) in UPnP and unique device identifier (DNS TXT records) in
> Zeroconf.

Would it be more convenient to unpack that for the client in a
strucured way? That is, it sounds like the opaque config string may
only be useful if the client app already has knowledge of particular
devices. Should the API provide that identifier (unique device id?
device descriptor doc?) in parsed form? Or are there too many or too
much variation for that to make sense?

I don't know that a special user opt-in for this info makes sense --
my question is more about what the client will use it for, and whether
the UA can do a better job of presenting
it, or if it'll be hard to use, should just not present it at all.

[defaults]

> That's a good point. The spec doesn't yet have wording to this effect. I
> expect we could add it at Step 13 of the getNetworkServices algorithm,
> changing it to something like "Optionally, e.g. based on a
> previously-established user preference, for security reasons, or due to
> platform limitations, the user agent may "... return a pre-defined
> successCallback or throw an errorCallback. The wording here would need some
> work ;)

I was looking at Step 10. Collapsed:

4.1 ... When the getNetworkServices(type, successCallback[,
errorCallback]) method is called, the user agent must run the
following steps:
...
10. The user agent must prompt the user in a user-agent-specific
manner for permission ...

I suggest changing this to something along the lines of "The user
agent must not provide the entry script's origin [...] without prior
permission given by the user." or something like that to communicat
that the user and UA can team up to make defaulting possible -- the
point being the UA has a responsibility to the user not to do things
without permission, but they can get an understanding of that
permission without explicit prompting at every invocation.


[intents]

> Based on our current thinking this API should allow a user to select
> multiple devices in a single getNetworkServices request (resulting in
> multiple NetworkService objects returned in the NetworkServices callback). I
> think that's different from the thinking for rPH and WebIntents (interaction
> is with one item at a time due to the provider page loading overhead
> required), though otherwise the interfaces could likely be almost identical.

There's nothing preventing web intents from returning multiple objects
-- arrays are serializable and we've been discussing how to format
that. In any case, the "NetworkServices" object or some analog could
potentially be serializable.

This isn't saying they should be the same API, even if they could be
-- there's plenty of good reasons to prefer dedicated APIs. I'm just
trying to understand the differences. I'm quite certain that in
Chrome, we'd be inclined to use the same user-facing UI elements to
get user permission for this API and use the same defaulting
strategies.

-Greg

Received on Thursday, 27 September 2012 23:32:08 UTC