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

Re: Audio Workers - please review

From: Chris Wilson <cwilso@google.com>
Date: Wed, 27 Aug 2014 11:28:57 -0700
Message-ID: <CAJK2wqXnEwb_nv_+anQq-ZA+KA2ws=HMt5OHMS1SYxV5g-xiNg@mail.gmail.com>
To: Joseph Berkovitz <joe@noteflight.com>
Cc: Olli Pettay <olli@pettay.fi>, "public-audio@w3.org" <public-audio@w3.org>, "Robert O'Callahan" <robert@ocallahan.org>
On Wed, Aug 27, 2014 at 11:07 AM, Joseph Berkovitz <joe@noteflight.com>
wrote:

> A couple of questions on this idea:
>
> 1. What about terminate()? Would you support that?
>

I'm on the fence.  It would be easier to specify exactly what happens (node
input is disconnected from node output, node is pass-through, whatever), so
yes.  It's probably valuable to explicitly kill the processing.


> 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 know that any other features added to Worker would be interesting
to add.  We'd likely need to carefully consider their effects in this case
anyway, since the behavior of this type of "worker" is pretty specific to
audio.  Short answer, I think, is "no".


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

The model is different from Web Workers usage, where you create an object
("new Worker()"), and then you use that object.  In ServiceWorker, you call
an instantiation mechanism ("navigator.serviceWorker.install(....);") and
then use the object your promise is resolved with.  Here, if we use a
sub-object, we're saying you call an instantation method
("context.createAudioWorker(...)") and then use an object that is a
sub-object of the mechanism you're returned (because yes, I definitely
agree the worker should be auto-instantiated by the AudioWorkerNode
creation).
Received on Wednesday, 27 August 2014 18:29:24 UTC

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