Re: New name for "AudioWorker"

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.
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>