- From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Date: Fri, 08 Feb 2013 18:43:02 +0100
- 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. JCD: OK. 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 JC > >>>>> >>>>>> 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