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

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

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Date: Fri, 08 Feb 2013 18:43:02 +0100
Message-ID: <51153926.7040809@telecom-paristech.fr>
To: public-device-apis@w3.org
Le 8/2/13 13:23 , Rich Tibbett a écrit :
> 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.
I really hate this choice, but I think I understand why you are doing 
it, so I'll shut up.

> 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.
JCD: I agree with this, and I never said 'remove', but 'updated': 
entries could safely be added to the initial NetworkServices object. If 
so, then the NetworkServices object could stay the same always for a 
given page/type(s).

>>> 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.'.
JCD: I agree
Best regards

>>>>>> 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

JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Friday, 8 February 2013 17:43:31 UTC

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