W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2016

Re: order of AudioWorkletGlobalScope script application

From: Ian Kilpatrick <ikilpatrick@google.com>
Date: Mon, 3 Oct 2016 09:47:02 -0700
Message-ID: <CAJL3UpTjJXGn3c_uh7Du1UUihYB8Fo_hSLVW54HD=b+6=UkOhw@mail.gmail.com>
To: Hongchan Choi <hongchan@google.com>
Cc: Joe Berkovitz <joe@noteflight.com>, Audio Working Group <public-audio@w3.org>
That's right; once the worklet infra. in each of the implementations
supports module loading, it should just work (tm).

On Fri, Sep 30, 2016 at 8:55 AM, Hongchan Choi <hongchan@google.com> wrote:

> Agreed. I believe ES6 module loading is a platform change so we don't need
> to do anything on our side. If the WorkletGlobalScope supports ES6 module
> loading, should AudioWorklet have it as well.
>
> On Fri, Sep 30, 2016 at 8:49 AM Joe Berkovitz <joe@noteflight.com> wrote:
>
>> I would suggest that we rely only on Worklet::import() semantics right
>> now and leave module loading for a future revision.
>>
>> .            .       .    .  . ...Joe
>>
>> Joe Berkovitz
>> President
>> Noteflight LLC
>>
>> +1 978 314 6271 <(978)%20314-6271>
>>
>> 49R Day Street
>> Somerville MA 02144
>> USA
>>
>> "Bring music to life"
>> www.noteflight.com
>>
>> On Fri, Sep 30, 2016 at 11:41 AM, Hongchan Choi <hongchan@google.com>
>> wrote:
>>
>> To clarify the context:
>>
>> 1. We still need to use Worklet::import() for the worklet script loading.
>> 2. ES6 module loading can be used in the worklet script to structure the
>> dependency.
>>
>> I was a bit confused by the new module loading pattern.
>>
>> On Fri, Sep 30, 2016 at 8:35 AM Hongchan Choi <hongchan@google.com>
>> wrote:
>>
>> (Oops. Ian just replied it few seconds before...)
>>
>> Another interesting direction to look at is ES6 module loading
>> <http://www.2ality.com/2014/09/es6-modules-final.html>. I still need to
>> do some catch up with the progress has been made so far, but it seems like
>> the worklet infrastructure will adopt this feature.
>>
>> Notably, this might change our `import()` and `registerProcessor()`
>> interface. Or do we support both?
>>
>> On Thu, Sep 29, 2016 at 2:50 PM Joe Berkovitz <joe@noteflight.com> wrote:
>>
>> I was unclear on the ordering, but the Worklet spec does mention that if
>> you import two scripts, the order of loading is indeterminate.
>>
>> This fetch vs. parse sequencing thing is the main point I was hoping Ian
>> could clear up for us.
>>
>> .            .       .    .  . ...Joe
>>
>> Joe Berkovitz
>> President
>> Noteflight LLC
>>
>> +1 978 314 6271 <(978)%20314-6271>
>>
>> 49R Day Street
>> Somerville MA 02144
>> USA
>>
>> "Bring music to life"
>> www.noteflight.com
>>
>> On Thu, Sep 29, 2016 at 4:45 PM, Hongchan Choi <hongchan@google.com>
>> wrote:
>>
>> Since this is already specced in the worklet spec, I don't think we need
>> to redefine our own storage for this purpose. We can simply use this notion
>> and add a link to the worklet spec.
>>
>> Also it seems like this follows the order of 'fetching', not parsing. Is
>> this what we want? Can we import multiple files concurrently?
>>
>> On Thu, Sep 29, 2016 at 7:32 AM Joe Berkovitz <joe@noteflight.com> wrote:
>>
>> Hi Ian,
>>
>> A question came up yesterday in conversation, about the order in which
>> imported scripts are applied to a WorkletGlobalScope. I realized that we'd
>> never discussed this in the WG, and that it would be desirable to apply
>> scripts to every global scope in a consistent order. My guess was that this
>> order should be the order in which Promises returned from various
>> importScript() calls are resolved, and that a given Worklet would need to
>> maintain some kind of internal list that captured the scripts' parse
>> results this order.
>>
>> On perusing the Worklet spec more carefully, I found this:
>>
>>     https://drafts.css-houdini.org/worklets/#module-responses-map
>>
>> Is the "module responses map" the very thing I was thinking about?
>>
>> Thanks for your help!
>>
>> Best,
>>
>> .            .       .    .  . ...Joe
>>
>>
>>
>>
Received on Monday, 3 October 2016 16:47:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 3 October 2016 16:47:33 UTC