Re: Discovery API proposals: call for comments

Claes,
thanks for your overview.

I think our proposal take a slightly different approach though. We didn't  
try to have an API that could allow full control of the discovery process.  
We focused more on giving an application the ability to retrieve  
"available" services. If there is a discovery process behind it, if this  
discovery process run before or after the application ask for a specific  
class of services, is transparent to the application. The application is  
only allowed to ask "notify me if/when some services of this type are  
available".

I personally think we could extend this concept and imagine that discovery  
(as in network discovery protocol a-la UPnP) is only one possible way of  
discovering services. A service may be running on the same box and being  
expose by the user agent as available, so without any real need for actual  
discovery. Such approach could be used as an alternative to service  
specific APIs to use functionalities available on a device (or at least as  
a way to start some prototyping before standardizing specific API for  
specific services). Anyway I haven't refined this idea more than this and  
the current proposal, while it could be used in this way,doesn't  
explicitly outline this use case.


/g


On Mon, 26 Sep 2011 16:40:47 +0200, Nilsson, Claes1  
<Claes1.Nilsson@sonyericsson.com> wrote:

> Hi,
>
> Related to the issues discussed below I would like to describe the  
> simple model for how the Webinos Service Discovery API manages the  
> situation when services became unavailable and how callbacks are used.
>
> Service discovery is performed through the findServices() method. There  
> is an options parameter stating the maximum time the asynchronous  
> discovery process will go on. For each discovered service an onFound  
> callback is issued. This makes it possible for the web application to  
> e.g. create a selection list of discovered services. If a previously  
> found service gets unavailable an onLost callback is issued that e.g.  
> makes it possible for the web application to remove that service from  
> the selection list.
>
> When a service has been selected the application calls bind(), which  
> makes it possible to access the service through a defined JavaScript  
> API. If a bound service gets unavailable the user agent calls the  
> onServiceUnavailable callback and when an unavailable service gets  
> available again onServiceAvailable is called.
>
> This is a simple model. When it comes to permissions and privacy the  
> current version of the Webinos Service Discovery specification relies on  
> the Webinos security framework. However, as a potential W3C standard  
> permissions and privacy will have to be specified within the Service  
> Discovery specification itself so there is room for further work here.
>
> Comments?
>
> Claes
>
>> -----Original Message-----
>> From: public-device-apis-request@w3.org [mailto:public-device-apis-
>> request@w3.org] On Behalf Of Rich Tibbett
>> Sent: den 26 september 2011 15:38
>> To: Giuseppe Pascale
>> Cc: Cathy.Chan@nokia.com; N.V.Balaji; public-device-apis@w3.org
>> Subject: 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
>>
>


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 29 September 2011 10:21:58 UTC