Re: change proposal for Telephony API

Hsin.Yi made very good points below. I think the current proposal with two
Telephony-realted objects in navigator is weird. If we go forward with
multiple objects let's do it consistently

best


El 18/04/13 10:58, "Hsin-Yi Tsai" <htsai@mozilla.com> escribió:

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



________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Thursday, 25 April 2013 10:54:20 UTC