Re: V2 of DTMF - the "Object Oriented" approach

On 1 December 2012 17:30, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:
> I think it should be a FIFO. Otherwise, when does a tone get removed from
> the buffer? After the initial task has been queued? After the tone is passed
> off to the thread ultimately responsible for sending it? After that thread
> has passed the data to the OS? After the tone duration (plus maybe
> inter-tone spacing) has elapsed? If so, when do you _start_ that timer (any
> of the preceding being candidates)? When do you stop it? I.e., there are
> also lots of choices for what "after" means.

I'm less concerned about loss in the stack than you are, clearly.  If
the tone gets lost anywhere, in the browser or network, too bad.
Chances are, it wont.

I would just write a routine that did the following:
 - pull next tone from list
 - dispatch for sending tone
 - dispatch tone event
 - schedule timer for next tone

All this would need to be synchronous with any reads on the
FIFO/string, and I'd probably just run that code on the main thread,
it's not that expensive.

> Make it a FIFO, and don't worry about the ability to abort... if an
> application wants to change its mind about what tones to send, it can queue
> them itself and only call insertDTMF with the next tone after it receives
> the event for the previous one, as Martin suggested. This seems much simpler
> to reason about for both JS application and UA.

Either approach could be made to work.  Regardless of the choice,
exposing a 'pendingTones' string in the API would be a courtesy that I
encourage.

Received on Monday, 3 December 2012 20:13:46 UTC