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

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

Best regards
JC

>
> See towards the end of Section 5.2 (which actually seems like an odd place
> for this text).
> [[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.


>
> Regards, Cathy.
>
>> Thanks
>> JC
>>
>> 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. I would rather think the object the listener is
>>> registered on is mutated prior to the dispatch of the event.
>>>
>>>> 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).
>>
>>
>> --
>> 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 Thursday, 7 February 2013 22:30:11 UTC