Re: New name for "AudioWorker"

Yes, thanks.

That said, there are a number of problems with this draft, so we can't use
it for our purpose just yet, I'm going to file issues upstream and we can
work there.

Cheers,
Paul.

On Sat, Oct 17, 2015 at 1:18 AM, Ian Kilpatrick <ikilpatrick@google.com>
wrote:

> I've updated https://drafts.css-houdini.org/isolated-workers/ to describe
> what HoudiniTF is roughly thinking.
>
> Thanks,
> Ian
>
> On Thu, Oct 8, 2015 at 8:52 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> Keep in mind I'm not suggesting the Worker infrastructure for EACH custom
>> audio processor - or even for each type instance.  There's ONE worker
>> thread, that all of audio runs in.
>>
>> On Thu, Oct 8, 2015 at 6:17 AM, Paul Adenot <padenot@mozilla.com> wrote:
>>
>>> "Not run continuously", as in, you don't decide when it runs and when it
>>> does not. You can't wake it up. This is not compatible with event loops as
>>> spec-ced today.
>>>
>>> In any case, the current worker infrastructure is way to heavy for any
>>> of the applications we want here.
>>>
>>> Paul.
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 7, 2015 at 8:34 PM, Alex Russell <slightlyoff@google.com>
>>> wrote:
>>>
>>>> On Wed, Oct 7, 2015 at 9:48 AM, Paul Adenot <padenot@mozilla.com>
>>>> wrote:
>>>>
>>>>> On Wed, Oct 7, 2015 at 6:32 PM, Chris Wilson <cwilso@google.com>
>>>>> wrote:
>>>>>
>>>>>> I'm actually off-the-cuff against trying to boil the ocean of the
>>>>>> general pattern.  This is pretty specific - the new thing , runs *IN*
>>>>>> something that can be a Worker-like process, but they're expected to share
>>>>>> the process.  The thing you can instantiate lots of (runtime contexts?) run
>>>>>> inside that process.
>>>>>>
>>>>>
>>>>> It might look like a worker-like process, but is actually pretty
>>>>> different: it does not run continuously, for starters.
>>>>>
>>>>
>>>> We have a variant of this in both Shared Worker and Service Worker. Why
>>>> is this different than those?
>>>>
>>>>
>>>>> I was expecting we would rename AW to CustomAudioProcessor, still
>>>>>> define them as running inside a Worker (and define how that Worker-sharing
>>>>>> works), and use Worker messaging.  That seemed like the shortest path to
>>>>>> success.
>>>>>>
>>>>>
>>>>> Yes, but we've clearly shown that this cannot work, because workers
>>>>> bring in a model and APIs that can't work for us.
>>>>>
>>>>> We have the same model than what the CSS and video folk need
>>>>> (something happens on some thread, we run a bit of script on this thread).
>>>>> We also need light input from ECMA so we don't redefine too much things. I
>>>>> think it's the right way to do it to avoid wasting other people's time and
>>>>> have solid spec and implementations.
>>>>>
>>>>> Paul.
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Oct 7, 2015 at 9:16 AM, Hongchan Choi <hongchan@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Nothing forces workers to be heavy weight, but doesn't it have the
>>>>>>> assumption that it runs on its own thread? What we want is to be able to
>>>>>>> throw JS code into VM that runs on the audio thread.
>>>>>>>
>>>>>>> Perhaps we can break that assumption, and propose a new type of
>>>>>>> Worker.
>>>>>>>
>>>>>>> On Wed, Oct 7, 2015 at 9:09 AM Alex Russell <slightlyoff@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Why isn't this thing a worker? What forces workers to be
>>>>>>>> heavyweight?
>>>>>>>>
>>>>>>>> Also, would be good to align with the Houdini folks on this as
>>>>>>>> they're proposing similar things in the rendering and compositing space.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> On 7 Oct 2015 7:52 a.m., "Paul Adenot" <padenot@mozilla.com> wrote:
>>>>>>>>
>>>>>>>>> We need to decide for a new name for something that:
>>>>>>>>>
>>>>>>>>> - Runs off-main-thread
>>>>>>>>> - Has access to a very limited set of APIs
>>>>>>>>> - Can be instantiated a lot of times in the same document (much
>>>>>>>>> more than Workers can or would)
>>>>>>>>> - Is specialized to one domain (audio, video, etc.)
>>>>>>>>> - ... ?
>>>>>>>>>
>>>>>>>>> It is likely that we would be the first group to spec something
>>>>>>>>> like this, but it would be used by other groups (layout people, video/image
>>>>>>>>> processing folks, etc.). We need something that is not too tied to audio,
>>>>>>>>> or can be adapted. I propose "Processor", which conveys the meaning of
>>>>>>>>> taking something as input, applying a transformation, and outputting it.
>>>>>>>>> I'm very open to suggestions though, this is merely to get the ball rolling.
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>> Paul.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>