Re: Discovery API proposals: call for comments

Giuseppe Pascale wrote:
> On Mon, 26 Sep 2011 08:10:30 +0200, N.V.Balaji <nv.balaji@samsung.com>
> wrote:
>>>
>>> I also have a mild preference for some notification when new services
>>> are
>>> available.
>>>
>>> I have 2 options in mind (with a preference for option #1):
>>>
>>> #1
>>> Have the successCallback to be called each time there is an update.

[snip]

>>
>> [NVB]: This seems to be an interesting idea. But typical semantics of
>> a success callback is to get invoked only once - Isnt't it?
>>

The API is intended to work as follows:

1. Web page requests a service type.
2. UA presents the services of that type available.
3. User selects one or more services from that list *once*.
4. Web page is provided with the services selected by the user in a 
single callback *once*.

So given 5 potential service candidates, a user may choose to connect 
e.g. one, three or five services to the web page.

It's only one callback when the user has selected something. It's never 
about giving a web page carte blanche access to all services with 
multiple repeating callbacks unless the user is consulted about that 
service sharing first.

>
>
>>
>>>
>>> Such a solution would address also another usecase:
>>> you may be in a situation where your services are always available
>>> (from a network point of view), but the user may start authorizing
>>> only (say) 1 (so that is returned by getNetworkServices); later the
>>> user (via a UA menu) decide to authorize access to more services.
>>> This, from the application point of view, should be threated as a
>>> "new service available" even though the service has always been
>>> available.

This is the intended behavior for the API as it stands. UA UI/UX 
behavior is beyond the scope of such a spec so we don't go in to all the 
details. To a developer, a new service is anything not yet connected to 
their web page, regardless of how long it's been connected to the network.

>>
>> [NVB]: is it not possible with the existing spec ?
>>
>
> Possible but not clear I would say. Basically depends from how the user
> agent implements it, since ultimately is the UA that notify the
> application about new services.
> This is one of the key point of the proposal: the UA control discovery,
> so we are not doing a 1:1 mapping with the underling discovery protocol
> (for security reasons).
>
> We may want to emphasize this in some informative text; Rich, what do
> you think?

There is no intention to provide multiple getNetworkServices callbacks 
on a single API call. The web page can re-call getNetworkServices at any 
time at which point the user can choose to share more or less services 
with the current page. That's entirely the user's choice and the user is 
in control of what's shared and when it's shared.

>
>
>>>
>>> #2
>>> Additional event in addition to onmessage and onreadystatechange.
>>> something like onmoreservicesavailable (name is just an example).
>>> The only concern I have with this approach is if having this event
>>> (and actually also the ServicesAvailable attribute) as an attribute
>>> of one specific service object is appropriate.
>>
>>
>> [NVB]: This interface, if present, should be part of
>> NavigatorNetworkService and NOT NetworkService
>>
>>

I sort of agree though there is certainly a privacy aspect to doing 
this. I don't particularly want this to be behind yet another 
authorization screen. So it either has to be a.) abstract enough to not 
encroach on the user's privacy (i.e. don't allow web pages to profile my 
network of devices) or b.) be provided behind a pre-existing 
authorization process.

We've chosen the latter. We first let the web page request service 
access. If they are provided with at least one service object then they 
should also be able to monitor, at an abstract level the services of the 
same type joining or leaving the service as part of that same 
authorization. It's then up to web pages to manifest their own in-page 
UI to re-invoke getNetworkServices if desired (e.g. 'Hey, it seems like 
more services are available! Click here to review your current service 
sharing and add and remove shared services.').

Effectively, we get to put two permissions (to access a service and to 
monitor for other similar services) behind one user authorization dialog.

I should note that if you request getNetworkServices and no services 
matching the request service type are found, the error callback returns 
immediately. So there's no need to know if a service exists prior to 
calling getNetworkServices. The web page will get the message soon 
enough after that invocation.

RE: Placing those otherservicejoined/otherserviceleft events on 
callbacks: perhaps the getNetworkServices callback should return a 
top-level manager-style interface (e.g. a 'ServiceManager' interface) on 
which 'servicejoined', 'serviceleft' and 'services[]' attributes can sit (?)

>
> yep, so basically my proposal would be to merge my point #1 and #2 as
> explained above.
>
>>>
>>> On a different topic, one more question: what should happen if the
>>> following happens
>>> 1) a service leave the network (e.g. UPnP bye bye)
>>> 2) you call getNetworkServices. Should the callback still return the
>>> service with readyState set to unavailable or should the callback do
>>> not return that service?

The callback won't be able to return this service because is doesn't 
appear as a selectable device in the UA's service authorization dialog. 
Or it does. That's a UA design choice IMO and doesn't need to be in 
scope of this spec.

>>
>>
>> [NVB]: As far as my understanding goes, onreadystatechange would have
>> got fired when the service became unavailable and getNetworkServices
>> would NOT return this object (based on the Algo specified in section
>> 4.11)
>>
>
> This is an option, but we should consider (thinking aloud here) if we
> want to go for a model where a device may be returned even if
> "unavailable".

We can leave it to implementers. If they want to let users select 
services that are offline then they can present them in the user 
authorization dialog. If they don't, they won't present them and they 
therefore can't be returned to the web page.

> In such a model the UA would be responsible for deciding when a device
> is "gone" (and should be removed by such a list) and when is still worth
> keeping it in the list as "unavailable". Use cases I have in mind here
> are 2:
> * the UA may want to be robust against short cycles of
> available/unavailable/available (for whatever reasons they happen)
> * there could be devices that even though unavailable could be waken up
> (e.g. via Wake-on-lan). Of course support for this would require some
> more details to be specified, but if the overall architecture support it
> we can extend it to support such protocols.
>
>
>> Thinking about the re-invocation of getNetworkServices, I have couple
>> of more questions:
>>
>> 1. should we remove the service from the whitelist, if it leaves the
>> network?

You can't really yank an object that was previously returned to the web 
page in the getNetworkServices object. The information contained therein 
would have since been propagated around the whole JS application.

You can remove the URL from the services whitelist. I think we should do 
that in case the user joins a new network and inadvertently gets access 
to another service/device on the same URL. This should be added as a 
step in the network leaving algorithm in Section 6.3.

>
> Good question, I'm not sure there is a good answer though. If we remove
> it, and ask the user to accept it again once he comes back to life, I
> see 2 main issues:
> 1. poor user experience if for some reason the device goes on and off
> frequently (standby?)
> 2. some user may want to configure their network whitelist once and not
> having to approve these devices everytime. As we discussed in the web&tv
> IG, this may be particularly handy for elder people or people with
> disabilities that may ask someone else to configure their setup.

AFAICS, this should be left as an implementation decision.

>
> Anyway, since this security mechanism is controlled by the user agent, I
> think the ultimate decision should be left to the UA. I would say the UA
> may remove that device from the whitelist, but the UA may also enable
> the user to manually configure a list of devices that an application is
> allowed to access, so that each time that application is used it
> automatically gets access to those devices.

I agree.

>
> Does this sound fine or are there concern about this approach?
>
>
>> 2. If all services that are available are found to be in the
>> whitelist, should step 10 (prompting the user for access grant) be
>> invoked again? IMO, user should be prompted only for services that are
>> not part of the whitelist
>>
>>
>
> agree. as mentioned before, we should also discuss if the UA may have a
> static setting of which devices are authorized so that it does not need
> to ask the user each time.

Any UA specific behavior is out of scope of this spec work and a lot of 
the feedback here is proposing normative UA-specific behavior.

A lot of this will benefit from one or two solid prototypes. Discussing 
at a theoretical level is dandy but there's nothing like well-executed 
code to explain things thoroughly.

- Rich

Received on Monday, 26 September 2011 13:38:09 UTC