- From: Greg Billock <gbillock@google.com>
- Date: Thu, 27 Sep 2012 16:31:41 -0700
- To: W3C Device APIs WG <public-device-apis@w3.org>
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