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

Martin Thomson wrote:
>> Are you proposing that the buffer is a FIFO? I'd thought that the buffer
>> would be a string that was reset on a new tone. FIFO's fine with me (but
>> then we need an "abort" call too).
>
> FIFO doesn't necessarily imply abort, but I didn't consider that
> consequence.  In the interests of simplicity, let's say that the
> string, which replaces the existing string will suffice.  If you want
> varying lengths, then you can use the existing.

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.

Right now the tone appears to be removed as part of the "asynchronous" 
steps, so the application appears to have no way to know exactly what 
its call to insertDTMF will replace. As an application developer I would 
find it very difficult to reason about which tones will actually get 
sent out even if I knew the answers to the above questions (I think some 
of them are answerable from your proposal, but it's not clear to me 
those are the "right" answers), and as an implementor I'd need such 
answers to make something interoperable, and in the process create lots 
of corner cases to check that I don't think have any real value.

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.

Received on Sunday, 2 December 2012 01:31:13 UTC