| 16:12 | <yulia> | Kris Kowal: ok, I think I don't understand why the origin needs to be in EcmaScript. Is this to allow emulation of the html loader? should this be something that is on the html side, where we serialize it, and then when deserializing it we do a check? It may be that I am unfamiliar with the use case. |
| 16:13 | <yulia> | I think that this is different than the above mentioned module graphnode instance, correct me if i am wrong and these are intrinsically related |
| 18:09 | <Kris Kowal> | Origin does not need to be in ECMAScript. |
| 18:22 | <Kris Kowal> | Much of this conversation about module graph replication is scoping out the shape of the ECMAScript side necessary to ensure HTML integration is coherent. To that end, there’s an internal slot for host data on module records today that we’re proposing will need to get distributed between internal slots of the module source record and module instance record. |
| 18:22 | <Kris Kowal> | Specifically, we anticipate that in all of the proposed design families, for HTML integration the origin information would have to move from the module record to the module source record. |
| 18:25 | <Kris Kowal> | In the second design family, the host-specific data on a module source record would need to go on to include the full URL and that the host-specific import behavior would use that as the key for its module map. Module instances would adopt their local module subgraph wholesale from the existing host-specific URL-to-module-map. |
| 18:27 | <Kris Kowal> | (with the caveat that the keys of the module-instance-map are keyed on import specifier, not fully resolved module specifier, which is the URL in web and node per-realm module-map) |
| 18:33 | <Kris Kowal> | Caridy’s proposal is consistent with all of the design families and HTML integrations as a baseline. |
| 18:40 | <Kris Kowal> | However, Luca Casonato’s proposed design may create a complication for the behavior of new ModuleInstance(moduleSource) if you’re trying to emulate HTML integration in user code. An HTML host would be able to look at moduleSource.[[HostData]].[[URL]] and observe that it already had an instance with that URL in its realm-scope module-map. My understanding is that the desired behavior in that case is that the new ModuleInstance(moduleSource) would evaluate to the existing ModuleInstance from the module-map, discarding the this, much like return override. To do that in user code would require a hook that Caridy’s proposal does not currently have. |
| 18:44 | <Kris Kowal> | Consider this case concretely: https://gist.github.com/kriskowal/53444bf8578338c366e300a6858870f5 |
| 18:47 | <Kris Kowal> | I believe Luca’s proposal will allow the host (for HTML integration) to ensure that there is only one instance of 2-job.js in the 1-worker.js realm. |
| 18:48 | <Kris Kowal> | An alternate interpretation is that there would in fact be two 2-job.js instances because of the separate new ModuleInstance(moduleSource) calls and otherwise, all their dependencies will be lifted out of the host’s realm module-map. |
| 18:50 | <Kris Kowal> | Updated the gist to reflect that conundrum. Luca Casonato is it your intention in your vision of the intermediate design family that the above program logs 'dep' and 'job' once or twice? |
| 18:52 | <Kris Kowal> | If the intended behavior is: Then Caridy’s proposal requires no modification. HTML integration can work like this and all the facilities are in place for HTML integration to be emulated with user code on say, a toaster oven. |
| 19:06 | <Luca Casonato> | I intend for that to log dep, job, job |
| 19:07 | <Kris Kowal> | Ah, well. That’s fine then. No complications. |
| 19:07 | <Luca Casonato> | The url exists in the source only to enable relative resolution, not do dedupe |
| 19:07 | <Luca Casonato> | And it would be URL + import map |
| 19:31 | <Kris Kowal> | Luca Casonato: Updated the Gist to reflect our shared interpretation since it’s not controversial between us. https://gist.github.com/kriskowal/53444bf8578338c366e300a6858870f5 |
| 19:36 | <Kris Kowal> | I am now on board with Luca’s original intuition and merging the two design families described as “ModuleSource is the unit of transfer” since this distinction implies no complications for emulating HTML behavior in user code. |