Re: Telephony API draft updated

> I don't think this change is a good idea.

Yes, it just tackled the visibility issue, but there other issues as well.
It looks like you responded to the last archived email, but the 2
latest messages (from Hsin-Yi Tsai and my reply) are missing from the
thread in the archive. Those should explain some more background for
this proposal.

>
> I agree that using the API before a call is started makes no changes
> that are visible to the user or possibly even to hardware.

Are you saying the API functionality should be dependent on whether
there is a call, or not?
So should it just silently do nothing audible, except setting internal
audio defaults, when there is no call (and not even return an error,
or raise an exception) and just work when there is a call?
[ Note that by having a call in the context of audio management, I
mean to have an audio stream, and not just that we have a
TelephonyCall object.]
With this you have basically illustrated why it makes all logical
sense to move it out from the Telephony object.
>From now on we are talking about a kludge, until we design this properly.


> However
> that doesn't mean that it doesn't make sense to have the API on the
> Telephony object.
>
> Consider for example the element.style.color API. This API allows
> modifying the text-color that an element is rendered in. If an element
> is removed from the document, the element is obviously not rendered at
> all. If we were to apply the same argument as is used for the
> telephony API, we shouldn't have an API like element.style.color since
> in some situations the API doesn't have any effect that is visible to
> the user.
>
> However the element.style.color API is very popular with authors. Not
> only because it is intuitive, I.e. the API to change an element is
> located on the element itself, but also because in some cases changing
> the color before an element is rendered makes the code flow for the
> application simpler. I.e. it allows the application to modify the
> color whenever you want. If that happens to not change something on
> the screen until later, or even at all, that's ok.

Are you suggesting that just because we happen to use color setting in
a particular way, which is popular, we should apply this pattern in
Telephony, despite it introduces ambiguity in API behavior?
I don't take this as a good argument.

>
> The call volume is a orthogonal property to any given call.

I agree with this. Volume control should actually be on the stream
(source volume, or sink volume).

> Imagine a
> dialer UI which displays audio controls like "speaker" and "microphone
> volume" at all times. It would certainly be possible for an
> application to create such a UI even with the API proposed here. The
> application would have to remember the state using application logic
> and once a TelephonyCall object becomes available it would modify
> those properties on that object right away. It would then switch the
> application logic such that when the user interacts with the UI it
> finds the closest TelephonyCall object and modifies that, rather than
> modifying the internal application state.

I have not yet seen such dialers, but maybe it's time to have them.
The world is changing.
Technically it is not impossible, since the app class is given
(telephony), so we may know the volume scale.
BTW what do you mean by "closest" TelephonyCall object?

> However it seems much more intuitive to put the audio properties on
> the Telephony interface. This way it's clear that the settings are
> per-call but rather global for all telephony interactions. And the
> application can always wire the UI directly up to API without having
> to switch between using application state or the API depending on if a
> TelephonyCall object happens to be connected. It also means that we
> won't have to address complex edge cases such as what happens if
> someone uses the API on a disconnected TelephonyCall object.

A disconnected call object obviously could not possibly set any
volume, since there is no audio stream.

>
> In short, we should focus on what creates a useable API.

Which should not be disconnected from the reality of how things work.

> We shouldn't
> focus on that the API has to map directly to hardware behavior. We
> also shouldn't focus on creating the API that is as simple as possible
> to implement. Application-author friendliness should be a higher
> priority than implementor friendliness.

For a first step could we agree in defining a separate interface for
audio etc controls, and include that object in Telephony API rather
than a bunch of properties?
Then, we may discuss later what would be a better place for it.

An updated proposal including volume scale:

[NoInterfaceObject]
interface TelephonyMediaControl : EventHandler {
    attribute boolean          speakerEnabled;
    attribute boolean          headsetEnabled;
    attribute double            audioVolume; // from 0.0 to 1.0
    attribute unsigned short audioVolumeSteps; // scale
    attribute boolean          audioMuted; // from 0.0 to 1.0
    attribute double            micVolume;
    attribute unsigned short micVolumeSteps; // scale
    attribute boolean          micMuted;

    attribute EventHandler onvolumechanged; // including muting
    attribute EventHandler onmicrophonechanged; // including muting
    attribute EventHandler onaudioroutingchanged;

    /** for future use */
    attribute boolean          frontCameraEnabled;
    attribute boolean          backCameraEnabled;
    attribute boolean          localVideoOn;  // send video
    attribute boolean          remoteVideoOn; // receive video
    attribute EventHandler oncamerachanged;
}


Best regards,
Zoltan

Received on Friday, 30 November 2012 09:22:11 UTC