Re: change proposal for Telephony API

Hi Zoltan,

I am not sure I got a clear difference between the interfaces 
TelephonyManager and TelephonyService. I am a little confused at the 
purpose and definition of TelephonyManager in this proposal. For 
example, I am wondering shouldn't onincoming and oncallschanged be 
exposed on TelephonyService since we can't receive any calls without 
telephony service, and since you propose a separate API for that 
service. It seems not intuitive to me that we use TelephonyService to 
make an outgoing call but receive incoming calls via TelephonyManager. 
Also, shouldn't each telephony service contain its calls?

In this proposal navigator.telephony is 'active' telephony service 
according to the comment. It looks not so right to me because there 
could be more than 1 active service at that same time. Isn't it? Or 
please let me know if I misunderstood something. Thanks!

Best regards,
Hsinyi

On 2013年04月17日 22:13, Kis, Zoltan 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
> };
> ======================
>
> An example on how cellular services could be implemented in Phase 2
> (shown here in order to demonstrate forward compatibility):
>
> interface CellularService : TelephonyService {
>      // telephony service (provider + SIM + modem) related interfaces
>      // if an interface is not supported, the property is null
>      readonly attribute SimInfo?                 siminfo; // IMSI, MCC, MNC, ...
>      readonly attribute SimSettings?          simsettings; //PIN, PUK, ...
>      readonly attribute SimToolkit?             simtoolkit;
>      readonly attribute TelephonyNetwork? network;
>      readonly attribute CallForwarding?      forwarding;
>      readonly attribute CallBarring?            barring;
>      readonly attribute CallMeters?            meters; // costs
>      readonly attribute USSD?                  ussd; // USSD, ...
>      // further extensible
> };
>
> Note that this proposal is independent from how conference calls are handled.
>
> Best regards,
> Zoltan
>

-- 
Hsin-Yi Tsai 蔡欣宜
Mozilla Taiwan
T: +886-2-87861100 ext:312
htsai@mozilla.com

Received on Thursday, 18 April 2013 08:58:48 UTC