2024-12-09
[11:41:29.0161] <kriskowal>
At plenary, I invited guybedford and MarkM to add ESM Phase Import follow-up to the TG3 docket since that’s a venue we can all converge upon.

MarkM informs us out-of-band that he has a conflict this Wendesday. I will be available to do a warm-up on the topic and may have tentative slides for framing the implications, but this will not be the high-value meeting if you need to optimize your celendar.

[11:47:19.0535] <guybedford>
I would be happy to start with an informal discussion on the topic, to follow-up with Mark's meeting in due course

[11:48:31.0080] <guybedford>
I will also be on holiday after this until Jan so maybe we can schedule the main follow-up for Jan 8

[11:52:40.0316] <kriskowal>
So it is written

[11:52:50.0217] <kriskowal>
(On the agenda)

[12:11:41.0779] <kriskowal>
nicolo-ribaudo: I believe an implication of ESM source phase imports merging in at 2.7 is that module sources + a dynamic import give you a capability to obtain the corresponding instance in the current realm. if/when we generalize this to evaluators or compartments, i think the champions will insist that the dynamic import behavior be scoped to the realm, compartment, or evaluators (what i’m calling the cohort). That seems to oblige us to entrain the notion of a realm-specific module map when or before we look at evaluators. Are there other motivations to absorb a module map in 262?

[12:12:52.0908] <kriskowal>
 * nicolo-ribaudo: I believe an implication of ESM source phase imports merging in at 2.7 is that module sources + a dynamic import give you a capability to obtain the corresponding instance in the current realm. if/when we generalize this to evaluators or compartments, i think the champions will insist that the dynamic import behavior be scoped to the realm, compartment, or evaluators (what i’m calling the cohort). That seems to oblige us to entrain the notion of a realm-specific module map when or before we look at evaluators. Are there other motivations to absorb a module map in 262 (factoring it out of HTML).

[12:15:13.0706] <nicolo-ribaudo>
My ideal spec shape would have a URL->source cohort-agnostic map in HTML, and a source->module map in 262

[12:16:05.0749] <nicolo-ribaudo>
Because I like leaving as little freedom to hosts as possible, without having to incorporate host-specific concepts in 262 to do so

[12:16:24.0297] <nicolo-ribaudo>
* My ideal spec shape would have a URL->source cohort-agnostic map in HTML, and a source->module per-cohort map in 262

[12:19:20.0655] <kriskowal>
That would work and I agree. What would motivate that refactor?

[12:21:02.0060] <kriskowal>
Just removing that degree of freedom seems likely to impact likelihood of correctness of frame to frame module source transfer in the implementation of ESM source phase imports as writ, assuming no further changes

[12:22:35.0865] <littledan>
URL+attribute -> source I imagine

[12:23:16.0944] <littledan>
this change would be potentially observable because it would imply consistently doing the HTTP caching. When we looked into this around the time of import attributes, there was resistance to making that requirement, and an assertion that it was already happening "in practice" (due to unspecified things)

[12:23:38.0589] <guybedford>
Interesting, that effectively makes Module Source Record the key, based on its own unique identity separate from ModuleSourcesEqual. That sounds like it could work!

[12:24:32.0394] <guybedford>
it could be a bit finnecky ensuring sources are distinct for distinct URLs though eg same source text for a.js and b.js must be separate Module Source Records seems a bit confusing too...

[12:24:39.0149] <littledan>
but because the caching isn't specified anywhere today, engines might feel the need to implement some sort of complicated multithreaded map, which could be expensive

[12:26:04.0258] <nicolo-ribaudo>
Presumably their [[HostDefined]] would be different (because it includes the URL), which explains why they are different records

[12:27:29.0522] <nicolo-ribaudo>
That missing caching is across multiple realms, right? An implementation doesn't need to cache more than today, but they'd need a way to say "if we had full caching, then these two sources would actually be a single source". But the proposal as it is today already does that 

[12:28:08.0701] <littledan>
yes, across realms (oh yeah that's single-threaded still)

[12:28:37.0025] <nicolo-ribaudo>
> <@kriskowal:aelf.land> That would work and I agree. What would motivate that refactor?

Is "I like it" a strong enough motivation? 😅

As long as this is entirely editorial, "it makes the spec behavior and requirements easier to understand" would be enough hopefully 

[12:28:46.0512] <littledan>
when does any of this have an observable effect? I guess when sharing the source to another same-origin iframe and observing that import() finds it in the cache?

[12:29:21.0954] <nicolo-ribaudo>
> <@littledan:matrix.org> when does any of this have an observable effect? I guess when sharing the source to another same-origin iframe and observing that import() finds it in the cache?

Yes this is the only case where we need to be careful as far as I know

[12:29:24.0811] <kriskowal>
The non-identity of namespaces for identical module sources over dynamic import in two frames makes the effect obserevable.

[12:30:14.0605] <littledan>
this sounds reasonable to me--ultimately, that should key off the host-defined stuff. *but* engines will need to consistently, always cache those responses across realms, and I'm not sure whether they are 100% sure that they are doing this today.

[12:30:46.0098] <littledan>
right, also just it executes the code 1 or 2 times

[12:31:24.0922] <kriskowal>
Do we have consensus in “both houses” that the observable effect I described above is implied by the 262 and web proposals collectively, such that an editorial refactor does not require a round at plenary?

[12:31:44.0332] <guybedford>
gotcha

[12:33:01.0579] <guybedford>
It seems 100% editorial to me

[12:34:08.0838] <kriskowal>
Good. Post-refactor, what key would dynamic import use to distinguish cohorts?

[12:34:33.0237] <nicolo-ribaudo>
The map would be per-cohort, and the cohort is captured by the dynamic import itself

[12:34:56.0046] <littledan>
which part do you disagree with?

[12:36:07.0164] <nicolo-ribaudo>
> <@littledan:matrix.org> this sounds reasonable to me--ultimately, that should key off the host-defined stuff. *but* engines will need to consistently, always cache those responses across realms, and I'm not sure whether they are 100% sure that they are doing this today.

They probably can get away with a check inside the dynamic import code to "be careful" when the specifier is a source coming from a different realm, and put it in some separate map

[12:36:53.0649] <nicolo-ribaudo>
> <@nicolo-ribaudo:matrix.org> The map would be per-cohort, and the cohort is captured by the dynamic import itself

I mean: the compartment/realm/cohort is some spec record with the map in an internal slot

[12:37:16.0065] <kriskowal>
The current realm is a parameter of dynamic import. I’d be content with a spec fiction of a single table where the realm participates in a composite key.

[12:37:46.0900] <littledan>
this sounds not totally trivial to get right

[12:39:11.0159] <kriskowal>
That is, if the cohorts are differentiated by the identity of each realm, or any of the other values that co-vary 1:1 with the realm like its corresponding global object, would work fine for every following plan I can imagine.

[12:39:47.0268] <kriskowal>
 * That is, if the cohorts are differentiated by the identity of each realm, ~or any of the other values that co-vary 1:1 with the realm like its corresponding global object~, would work fine for every following plan I can imagine.

[12:39:54.0352] <kriskowal>
 * That is, if the cohorts are differentiated by the identity of each realm, ~~or any of the other values that co-vary 1:1 with the realm like its corresponding global object~~, would work fine for every following plan I can imagine.

[12:40:37.0534] <kriskowal>
 * That is, if the cohorts are differentiated by the identity of each realm would work fine for every following plan I can imagine. Edit: I am not so sure of that 1realm:1global correspondence in all possible futures.

[12:41:02.0440] <kriskowal>
 * That is, if the cohorts are differentiated by the identity of each realm would work fine for every following plan I can imagine. Edit: I am not so sure of that 1realm:1cohort:1global correspondence in all possible futures.

[12:55:06.0008] <guybedford>
Every Module Source Record has a single [[Cohort]] field which in turn can point to its [[Realm]]. Then when using dynamic `import()` the [[Cohort]] is taken from the parent module's Module Source Record context. I think that should allow ECMA-262 to be fairly well-defined on these behaviours.

[12:55:46.0877] <guybedford>
that is `import(source` uses the [[Cohort]] from the dynamic import's parent module context (or if it is a script, the global realms "default cohort")

[12:56:00.0155] <guybedford>
 * that is `import(source)` uses the \[\[Cohort\]\] from the dynamic import's parent module context (or if it is a script, the global realms "default cohort")

[13:01:07.0384] <kriskowal>
Right, my intention is to introduce exactly this level of indirection from [[Realm]] to [[Cohort]].[[Realm]] in Evaluators, which should cover everything that precedes it.

[13:02:13.0405] <kriskowal>
So, provided that everything that lands before Evaluators is keyed on [[Realm]], everything should iron out. In particular, the behavior of dynamic import for a source.

[13:03:16.0142] <kriskowal>
And my understanding is that this is what you’ve specified, though it’s spread between 262 and web specs currently.

[14:01:39.0021] <guybedford>
Effectively, where we ban mismatching [[Realm]]s in the module records today, while that might be relaxed, in future that would become the compartment integration point.

[15:46:13.0890] <kriskowal>
I see. Banning mismatched realms means the observable behavior of transferring a module source to a shared-origin iframe is an error, which can be relaxed without breaking backward compatibility, and so is also forward-compatible with a relaxation to accommodate compartments. We consequently don’t have anything to refactor yet.

[15:47:59.0320] <guybedford>
Exactly, for reference this is currently step 10.b.iii in https://tc39.es/proposal-esm-phase-imports/#sec-evaluate-import-call


2024-12-12
[08:02:08.0334] <nicolo-ribaudo>
Is anybody else joining today?

[08:11:41.0330] <jakobjingleheimer>
Sorry yes i can. Meeting ran over

[09:00:01.0136] <jakobjingleheimer>
Transcript and notes from today's meeting: https://app.fireflies.ai/view/TC39-Module-Harmony::YZWA3JzT7z272QW9