- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Mon, 22 Apr 2013 22:51:07 +0300
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>, Mounir Lamouri <mounir@lamouri.fr>, "Mandyam, Giridhar" <mandyam@quicinc.com>, "SULLIVAN, BRYAN L" <bs3131@att.com>, "DRUTA, DAN" <dd5826@att.com>, EDUARDO FULLEA CARRERA <efc@tid.es>
On Mon, Apr 22, 2013 at 10:38 PM, Jonas Sicking <jonas@sicking.cc> wrote: > We should remember that we should optimize APIs for consumers of the > API, not for implementers of the API. We agree. First priority is the developers, then the implementers, then the spec. > > And in the case of the Telephony API the consumer will generally be > someone creating a dialer in some form, or something which monitors > incoming and outgoing calls. So that is what the API should be > optimized for, not what the underlying implementation needs to do. And that is what it tries to do: the minimum burden to handle the use cases. > > So I do think it's good that the call list is only in one central > location since in most UIs will want to manage them. I would similarly > move at least the error event to fire in a central location. Hsin-Yi actually had a good point. I went on and implemented it today, it wasn't a big burden. I don't have a strong opinion on this part - we can expose calls both on services and on the manager, no problem. Same with the events. > > The current proposal seems to be mostly a syntactic change to the existing API: > > navigator.telephony.dial(..., service); > vs > navigator.telephony.services[service].dial(...); No, there is no syntactic change. The way to dial remains navigator.telephony.dial(number); But telephony is a service now (used to be the manager), and we have a separate manager object. Actually this is very close to the original B2G API, but *that* manager is now a service, since there can be many services. In addition, another object manages the services. > > So I don't have a strong opinion one way or another. > > However one thing that will not work in the new proposal is the > synchronous API for enabling/disabling a service. Surely that needs to > be an asynchronous operation? Yes, surely, it is. The description should be more clear on this, i.e. setting the property just starts the operation. When the service is actually enabled or disabled, an event is generated and the handlers are called (onserviceadded, onserviceremoved). Best regards, Zoltan
Received on Monday, 22 April 2013 19:51:35 UTC