Re: Audio Workers - please review

On Thu, Sep 11, 2014 at 9:45 PM, Joseph Berkovitz <joe@noteflight.com>
wrote:

>
> On Sep 11, 2014, at 2:06 PM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
> On Thu, Sep 11, 2014 at 9:01 PM, Joseph Berkovitz <joe@noteflight.com>
> wrote:
>
>> Jussi,
>>
>> I agree the issue of importScripts overhead could be pretty major, if
>> this overhead is in fact likely to be substantial. I am not knowledgeable
>> about the extent to which browsers optimize imports of the same scripts in
>> multiple workers. However it is almost a certainty that nodes will want to
>> exploit substantial libraries.
>>
>> I did not see a convenient way in your proposed API to make it easy for
>> different nodes based on the same worker to partition their ongoing
>> computational state (maintained in between onaudioprocess callbacks) from
>> each other, though. Did I miss something? Doesn’t there need to be a
>> persistent per-node object that can hold this state?
>>
>
> The state can for example be provided by a closure in the
> onaudionodecreated event handler, or using a global WeakMap that uses the
> AudioNodeHandles as keys. This makes sure that the state associated to the
> node is garbage collected when the node is.
>
>
> I see.  Either of the above would work, but it feels like in this model
> the developer needs to do some more careful bookkeeping about state rather
> than just sticking state into the node’s dedicated global scope. That makes
> the approach feel more complex for developers to consume, relative to
> Chris’s proposal or the original ScriptProcessorNode.
>

What I think we'll be looking at as the majority of people writing code
that runs inside the AudioWorkers will be library authors. As an author of
more libraries than I care to admit, I'd personally rather learn how
closures work than get a barrage of bug reports from people using my code,
complaining that my code is making their applications glitchy (which I get
at the moment, btw), not being able to really do anything about it except
blame the API and bugs qualifying as blockers as WONTFIX.

The next biggest group, although likely much smaller, will probably be
people doing experimentation. Learning. While they're at it, they'll
probably want to learn the language as well.

In short, I don't think we have any target audience for the AudioWorker's
that'd have significant trouble understanding how closures work. If we do,
we should probably specify that group and add it to use cases list and
decide on how high the priority for catering to them is.


>
> …Joe
>