Re: New name for "AudioWorker"

Also I was writing a separate draft to spec this, but I'll hold off for now.

Paul.

On Wed, Oct 7, 2015 at 7:20 PM, Paul Adenot <padenot@mozilla.com> wrote:

> On Wed, Oct 7, 2015 at 7:12 PM, Ian Kilpatrick <ikilpatrick@chromium.org>
> wrote:
>
>> Hi all,
>>
>> Houdini is attempting to add extension points into the rendering pipeline
>> of browsers. Because of this we need properties similar to what is required
>> for AudioWorker (at the moment we've called it IsolatedWorker, fine with
>> changing the name to IsolatedProcessor or something <bikeshed-here>).
>>
>> I'm currently writing a draft of the spec at the moment and should appear
>> here (https://drafts.css-houdini.org/isolated-workers/) at the end of
>> the week.
>>
>> It will be based on the strawperson discussed at Houdini Paris F2F. (
>> http://bfgeek.com/css-houdini-drafts/css-script-api/Overview.html).
>>
>> A few properties that we'd like from this spec:
>>  - Thread-agnostic - that is, it does not define on which thread this is
>> run, may share a thread with something else, i.e. main document context.
>>  - Subset of APIs - remove network request APIs etc.
>>
>
> I'd rather have this opt-in (you pick the APIs you want) than opt-out (you
> remove some APIs).
>
>
> The rest is what we need indeed.
>
> Paul.
>
>
>>  - Hook based - APIs will be reached by registering callbacks on
>> GlobalScope, e.g. registerPaint() not event based.
>>  - Life-cycle - can be created/destroyed at defined points in time.
>> Similar to ServiceWorker.
>>
>
>> Additionally we've observed that javascript implementations have a high
>> memory overhead per javascript context. We believe we want to limit the
>> number created, so similar to the main javascript execution context, code
>> shares a single javascript execution context. Details of this is probably
>> better discussed one there is a proposal.
>>
>> Ian
>>
>> On Wed, Oct 7, 2015 at 9:32 AM, 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.
>>>
>>> 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.
>>>
>>> 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.
>>>>>>
>>>>>
>>>
>>
>