Re: change proposal for Telephony API

On Wed, Apr 17, 2013 at 7:13 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> Hello,
>
> Here is an alternative way to do Telephony, compatible with the
> previous version, but cleaner, better aligned with how telephony
> works, more extensible, and also aligned with the Messaging API.
>
> I kindly ask for comments at least from the persons named in the To field :).
>
> In the current API we support multiple services, but they are not
> exposed as objects.
> Only the serviceId's can be seen, and specified as parameters for
> methods like dial(), sendTones(), startTone(), stopTone(), and also
> for errors (e.g. on which service the error occured).
>
> Also, there were requests to support telephony services (like network
> selection, SIM info, call barring, call forwarding, USSD, etc) in
> Phase 2, the TelephonyService objects will likely be exposed in the
> API, but of course documented in a separate specification.
>
> The proposal here is to encapsulate the telephony service specific
> methods and error handling to service objects (just like with
> messaging), and expose the default service on the navigator object,
> along with the telephony manager object.
> This keeps the example unchanged:
> var telCall = navigator.telephony.dial('+1234567890');
>
> This design could also be applied to Messaging (in a separate email,
> later, eventually), by exposing an active/default service for sms,
> mms, (im, email) and the messagingManager.
>
> For comparison, the current design can be seen at
> http://telephony.sysapps.org/ .
>
> The WebIDL for the alternative proposal is here:
>
> ======================
>
> partial interface Navigator {
>     readonly attribute TelephonyManager telephonyManager;
>     attribute TelephonyService telephony; // active telephony service
> };
>
> [NoInterfaceObject]
> interface TelephonyManager : EventTarget {
>     readonly attribute CallHandler?  activeCall;
>     readonly attribute CallHandler[] calls;
>     readonly attribute TelephonyService[] services;
>
>     attribute EventHandler onincoming; // for incoming and waiting
>     attribute EventHandler oncallschanged;
>     attribute EventHandler onserviceadded;
>     attribute EventHandler onserviceremoved;
> };
>
> [NoInterfaceObject]
> interface TelephonyService : EventTarget {
>     readonly attribute DOMString serviceId;
>                  attribute DOMString displayName; // to be shown in a UI
>                  attribute boolean  enabled;
>     readonly attribute DOMString provider;
>     readonly attribute DOMString type;
>     readonly attribute DOMError  error;
>     readonly attribute DOMString[] emergencyNumbers;
>
>     attribute EventHandler onerror;
>
>     TelephonyCall dial(DOMString remoteParty, optional DialParams params);
>     TelephonyCall dialEmergency();
>     void sendTones(DOMString tones, optional ToneParams params);
>     void startTone(DOMString tone);
>     void stopTone();
> };
>
> [NoInterfaceObject]
> interface TelephonyEvent : Event {
>     readonly attribute TelephonyCall call;
> };
>
> [NoInterfaceObject]
> interface TelephonyServiceEvent : Event {
>     readonly attribute TelephonyService service;
> };
>
> dictionary ToneParams {
>     unsigned long duration;
>     unsigned long gap;
> };
>
> dictionary DialParams {
>     boolean hideCallerId;
>     // later: e.g. video related settings
> };

We should remember that we should optimize APIs for consumers of the
API, not for implementers of the API.

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.

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.

The current proposal seems to be mostly a syntactic change to the existing API:

navigator.telephony.dial(..., service);
vs
navigator.telephony.services[service].dial(...);

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?

/ Jonas

Received on Monday, 22 April 2013 19:39:00 UTC