- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Mon, 22 Oct 2012 13:23:39 +0300
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: EDUARDO FULLEA CARRERA <efc@tid.es>, "public-sysapps@w3.org" <public-sysapps@w3.org>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
- Message-ID: <CANrNqUeXuvUiyt7+A3wTeqaOh9zPA6gj3Qkdzygn8zaBjLBKaQ@mail.gmail.com>
Hello, On Mon, Oct 22, 2012 at 12:45 PM, Jonas Sicking <jonas@sicking.cc> wrote: The API as it's currently defined isn't enough to implement a > recording feature. There's no way to actually access the recorded > calls and play them to the user, and there's no way to specify the > file format parameters to be used to record the call. > > What do you mean by an API not being enough to implement a functionality? The API only exposes a functionality. My assumption was that implementation is native, and below web runtime. Or, do you want to handle AT commands and PCM interfaces from the web runtime? Including real-time constraints, security policies, etc? Where is the limit we define between native middleware territory vs functionality implemented in HTML5? I have a certain understanding of where that should be, but it seems it is different than yours :). I think in order to build a system which will work in practice, we need to get this part right, from the beginning. Then, it is true that recording a call may not be possible in certain hardware designs, depending on the modem audio path. In those cases this feature will not be implemented, and an error condition can be raised. > So I definitely think that we need to change the API from it's current > state. > It is easy to remove the recording feature, but I would not like to do it for the wrong reasons. > > > This is not minimalistic, but IMO it's simpler for developers. > > Generally speaking, we should only add features to simplify > development in cases when it's an operation commonly done by > developers. We can't ever solve 100% of the things that developers > might want to do. Especially by adding dedicated APIs for them. It's > much better to try to build enough primitives that the common use > cases are easy, and that the unusual ones are possible. > This is usually true, and I agree. But in this case it is a pretty easy thing, just an optional field in a dictionary. It is certainly not a dedicated API. > > I must admit to never having seen a phone UI which allows recording a > call, though I don't doubt that they exist. So my question is how > common of a requirement this is from users and phone manufacturers. > > Many phones do offer call recording, either via the native dialer, or via an app. Actually I have got many questions from users about supporting this feature. Best regards, Zoltan > / Jonas > --------------------------------------------------------------------- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > >
Received on Tuesday, 23 October 2012 18:09:08 UTC