W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2013

Re: [discovery-api] how does serviceavailable function in practice

From: Rich Tibbett <richt@opera.com>
Date: Fri, 08 Feb 2013 13:23:30 +0100
Message-ID: <5114EE42.5000804@opera.com>
To: public-device-apis@w3.org
Jean-Claude Dufourd wrote:
> Thanks for your answer Cathy, comments inline.
>
> On 07févr. 21:14, Cathy.Chan@nokia.com wrote:
>>> -----Original Message-----
>>> From: ext Jean-Claude Dufourd [mailto:jean-claude.dufourd@telecom-
>>> paristech.fr]
>>> Sent: Thursday, February 07, 2013 8:44 AM
>>> To: Bjoern Hoehrmann
>>> Cc: public-device-apis@w3.org
>>> Subject: Re: [discovery-api] how does serviceavailable function in
>> practice
>>> Thanks for the fast answer.
>>> If the serviceavailable event itself does not provide a way to get the
>>> NetworkService object, and the NetworkServices object received by the
>>> successCallback is immutable, where do I get the information ? Rich ?
>> Not Rich but still want to give it a shot. ;-)
>>
>> Upon receiving the serviceavailable event, the web app would most likely
>> want to issue a new getNetworkServices call to retrieve the fresh list of
>> available network services. A new NetworkServices object will be
>> provided at
>> the success callback.
> JCD: This is unacceptably inefficient.
> An entity that knows about the new NetworkService available sends a
> Event without that information ?

Yes. The web page never has access to a new NetworkService object 
without the users permission. To obtain that permission they re-invoke 
getNetworkServices() with the same set of service control types so we 
can ask the user, they can choose and the process starts over.

When the user agent displays the opt-in dialog resulting from a 
re-invocation of getNetworkServices() that dialog should pre-highlight 
the existing services shared with the web page (even if they're not 
online at the current time) and the user is free to add or remove 
services from that selection, click 'OK' and a new NetworkServices 
object is returned.

If the user doesn't add or remove services then that object should be 
_identical_ to the previous NetworkServices object returned to the page. 
Otherwise that object is most likely to be a combination of existing 
shared services and new services - all authorized by the user.

It's difficult to specify such things as this without overly 
constraining or over specifying user interfaces and user interaction for 
this API.

> Then the web application receiving the event needs to issue an
> asynchronous call, and wait for a callback from the entity that could
> have given a pointer to the NetworkService in the first place ?
>
> How about we stop using events and EventHandlers for onservice* and
> start using plain vanilla callbacks that provide the expected
> information directly ?
>
> Asynchronous calls should be used as parcimoniously as possible.
> Note: whether the actual callback is called immediately in that case is
> beside the point: the code has to be written in an asynchronous manner
> anyway, and that is much more error prone than straight synchronous code.
>
> If for some reason we have to absolutely use events for onservice*, the
> NetworkServices could be updated (why does it have to be immutable) ?

1. We need users to opt-in to the sharing at all times.
2. We should never remove _active_ objects from the JavaScript 
environment. e.g. if I've bound some functions to networkservices[2] 
(the second service returned in a successCallback) and that object then 
gets re-assigned to a new service dynamically, I'm basically in object 
management hell.

>
>>
>> See towards the end of Section 5.2 (which actually seems like an odd
>> place
>> for this text).

Perhaps we should move this to the bottom of Section 5. Any other 
suggestions?

>> [[Services available within the local network can connect and
>> disconnect at
>> different times during the execution of a web page. A user agent can
>> inform
>> a web page when the state of networked services matching the requested
>> valid
>> service type change. Web pages can use this information to enable in-page
>> experiences for communicating the state of networked services with the
>> ability to change the particular service or set of services the page is
>> connected to by re-invoking the getNetworkServices() method.]]
> JCD: This text actually talks about something else: "change the
> particular service or set of services the page is connected to". The set
> is constant in my question.

There is scope in the specification for user agents to return a new, 
identical NetworkServices object via the UI as I explained above. That's 
not really mandated in the specification because it is considered an 
implementation choice.

>>> Le 7/2/13 14:39 , Bjoern Hoehrmann a écrit :
>>>> * Jean-Claude Dufourd wrote:
>>>>> Let us imagine that after a first call to getNetworkServices, I get a
>>>>> NetworkServices object with 0 entries.
>>>>> So I have to listen to the serviceavailable event on that
>>>>> NetworkServices object to get any new matching service.
>>>>> Probably, the event handler is going to provide me with a new obect
>>>>> of type NetworkService. Is that correct ?
>>>> Based on the current Working Draft that would not be possible because
>>>> the `serviceavailable` event object implements only the Event
>>>> interface which lacks support for such information. That would also
>>>> seem to be odd design.

We don't set evt.target or any such attribute because that would 
explicitly bypass user opt-in. NetworkService objects are privileged. 
The only way to currently obtain user opt-in or new NetworkService 
object is to re-invoke getNetworkServices().

>>>> I would rather think the object the listener is
>>>> registered on is mutated prior to the dispatch of the event.

The NetworkServices.servicesAvailable attribute is updated prior to 
dispatch of the serviceavailable event.

On review, perhaps the immutability in NetworkServices should be 
clarified from 'A NetworkServices object is immutable meaning that 
indexed properties cannot be added and indexed properties cannot be 
removed for the lifetime of a NetworkServices object.' to 'The _indexed 
properties of a_ NetworkServices object are immutable meaning that 
indexed properties cannot be added and indexed properties cannot be 
removed for the lifetime of a NetworkServices object.'.

>>>>
>>>>> I did not find in the spec where this is specified.
>>>>> What did I miss ?
>>>> In <http://www.w3.org/TR/2012/WD-discovery-api-20121004/> section 7 in
>>>> the first list in the sublist in the fourth list the third item
>>>> mentions `serviceavailable`. You can then step back through the code
>>>> to see what effect the individual assembly instructions, like
>>>> "increment service manager's servicesAvailable attribute by 1" have
>>> (reverse-engineering).

Always open to rewrite proposals of course if there's any way to make 
this easier.

Thanks,

Rich
Received on Friday, 8 February 2013 12:23:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC