Re: Proposal: Fire a toneDiscarded event while discarding the invalid DTMF values.

On 06/13/2014 03:54 PM, tim panton wrote:
> On 13 Jun 2014, at 14:35, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>> So, I am sorry, but the argument of "Javascript can do it, so browser should not" does not sound like a good argument to me.
> That is exactly my argument. (better expressed than I’ve managed so far ;-) )
>
> If it can be implemented by the average javascript developer in 10 lines or can be neatly put into a simple library we shouldn’t
> put it in the browser.
>
> Every thing we add at this stage (and I’ve been saying this for 9 months) delays the standard, and complicates testing. 
> You have to be _very_ sure your favourite feature is worth the delay.
>
>

Tim, DTMF was added in order to have a surface to command the browser to
send RFC 4733 telephone-events, because people said that was required to
implement use case #3.4.2 ("Fedex Call").

Telephone-events can't be generated using WebAudio.

The interface we have in the spec now was finished a year or so ago. It
was thought at the time to be an interface that solved the problem, and
had as few bells and whistles above that as we could get away with.

To my mind, every message we spend on revisiting this inteface is a
waste of time. We satisfied our use case, we should go on.

Some people are saying we should change the text.
They need to show that the changed text fits better with satisfying use
case #3.4.2, OR that it makes life significantly easier for either
browser developers or Javascript developers.

If not, I see no point in changing it.

Given that -use-cases is not changing, I don't see ANY justification for
revisiting the issue of whether we have this API or not.



-- 
Surveillance is pervasive. Go Dark.

Received on Friday, 13 June 2014 14:19:14 UTC