W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: Audio Workers - please review

From: Joseph Berkovitz <joe@noteflight.com>
Date: Wed, 27 Aug 2014 14:07:11 -0400
Cc: Olli Pettay <olli@pettay.fi>, "public-audio@w3.org" <public-audio@w3.org>, Robert O'Callahan <robert@ocallahan.org>
Message-Id: <6919537D-7FE6-4990-9243-F6895068E968@noteflight.com>
To: Chris Wilson <cwilso@google.com>
A couple of questions on this idea:

1. What about terminate()? Would you support that?

2. What about any other features that ever get added to Worker in the future? Would we not want those to become visible in  AudioWorker as well?

I don’t think the additional nested object is hard to understand, especially since it implements an already familiar interface. Composition is cleaner.


On Aug 27, 2014, at 12:31 PM, Chris Wilson <cwilso@google.com> wrote:

> I'm leaning toward simply not directly implementing Worker, then, and adding postMessage/onmessage to the AudioWorkerNode interface directly.  I'd rather not have one more object hanging around (and have to explain that the onmessage has to be set on the .worker, not on the node, e.g.).
> On Tue, Aug 26, 2014 at 1:22 PM, Joseph Berkovitz <joe@noteflight.com> wrote:
> Hmm. I had been wondering about the feasibility of the interface mixin idea, although I liked the simplicity.
> If there is no precedent in other APIs for mixing in disparate classes like this, and it creates implementation discomfort, I lean towards the earlier approach in which the Worker was a distinct property of the AudioWorkerNode.
> However in that case I don’t see the need to construct the AudioWorker explicitly in a separate step and shove it into the node -- I’d suggest that it be “pre-manufactured” by createAudioWorker(), as part of the returned AudioWorkerNode. That seems kind of ideal: no separate step for the developer, but a clean separation of concerns for implementors.
> …Joe
> On Aug 26, 2014, at 9:38 AM, Olli Pettay <olli@pettay.fi> wrote:
>> On 08/26/2014 07:54 AM, Robert O'Callahan wrote:
>>> Ah, thanks.
>>> Mixing in a concrete class like that is likely to cause problems for implementors.
>> Yes, and the prototype handling would be rather unexpected.
>> AudioWorkerNode wouldn't have WorkerPrototype as prototype, but AudioNodePrototype.
>> And even more odd is that AudioWorkerNode would inherit EventTarget via AudioNode interface, but
>> re-implement EventTarget via Worker interface.
>> -Olli
>>> Rob
>>> --
>>> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
>>> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
>>> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo
>>> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso
>>> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo
>>> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo
>>> otohoeo ofoioroeo ooofo ohoeololo.
> .            .       .    .  . ...Joe
> Joe Berkovitz
> President
> Noteflight LLC
> Boston, Mass. phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"

.            .       .    .  . ...Joe

Joe Berkovitz

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
"Your music, everywhere"
Received on Wednesday, 27 August 2014 18:07:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC