Re: Telephony API draft

On Mon, Oct 22, 2012 at 3:23 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> 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.

Yes, the implementation is definitely native and doesn't need to rely
on a web runtime.

The reason that we're adding APIs is to enable app developers to
expose functionality to users, right? In this case, the goal seems to
be to enable app developers to expose a "record" button while
displaying an in-call UI. Or a checkbox somewhere in the UI to say
"record all my calls". Or something more advanced like "record all my
calls to this list of people". This is of course entirely up to
application logic.

However all of this is completely useless if the user isn't able to
somewhere also see UI which lists all the recordings and has the
ability to play them. I.e. there's no point in recording a call if the
user can't later listen to that recording. This UI doesn't need to be
in the same app, but it needs to be somewhere.

Right now, the API doesn't say where these recordings are saved. And
it doesn't provide the ability to enumerate or play any of these
recordings. As an app author, the recordings seems to go into a black
hole and I can't expose them to the user in any way.

So if I build a device based on this API, I would only be able to
build an app which has a "record" button, but no "play" button. This
is obviously a problem.

/ Jonas

Received on Monday, 22 October 2012 19:33:49 UTC