| 06:09 | <nicolo-ribaudo> | nicolo-ribaudo: In the extra time on the SES call, caridy agreed to add referrer, so new Module(source, referrer, …) and we are still working on the importMeta and importHook order/optionality. But, among us, we’ve arrived at importHook(specifier, referrer) for the hook signature. |
| 12:59 | <littledan> | what happened in that call? Sorry I missed it |
| 13:33 | <nicolo-ribaudo> | We reviewed Caridy's proposed spec for Layer 0 of compartments, and my host hooks refactor. Then they had the discussion about referrer vs importMeta. |
| 14:40 | <littledan> | how do people feel about the host hooks refactor? |
| 14:48 | <nicolo-ribaudo> | Yesterday there were no negative comments! We were unsure if it's editorial or normative, but it's something that we can figure out. I believe that the only potentially observable change from user code is that if you import the same module dynamically twice in the same file, the number of promise ticks needed to "call" the second import is now spec-defined rather than host-defined. |
| 14:49 | <littledan> | I think we'll continue to disagree on whether such a change is normative, but that shouldn't block it from landing :) |
| 14:50 | <littledan> | there's the argument that "layering" changes are not normative but just editorial refactoring, and there are people who see the host hooks as a critical layer with normative semantics. Either way, it should be reviewed in plenary since it's a big change. |
| 14:52 | <nicolo-ribaudo> | Yes I agree that we should not do this "silently" just with the editors |
| 14:52 | <littledan> | Has there been any more discussion on whether import reflection should give you a Module or ModuleSource/WebAssembly.Module? |
| 14:52 | <nicolo-ribaudo> | Nope |
| 14:52 | <littledan> | maybe we can put this on our modules call agenda next time? |
| 14:54 | <littledan> | one detail which we haven't explicitly discussed is that, if we go the Module way, we should allow people to ship this while initially rejecting if you directly import() a Wasm module. This is because implementing Wasm/ESM integration for instances is a lot of work, not so useful yet, and it shouldn't block getting access to the WebAssembly.Module |
| 17:45 | <Kris Kowal> | Would be weird if we get stuck in the intermediate state, where you can import the source but not the instance, indefinitely. But, I assume there’s not much risk of that. |
| 17:46 | <Kris Kowal> | I think we'll continue to disagree on whether such a change is normative, but that shouldn't block it from landing :) |
| 17:46 | <littledan> | Would be weird if we get stuck in the intermediate state, where you can import the source but not the instance, indefinitely. But, I assume there’s not much risk of that. |
| 17:49 | <Kris Kowal> | We should definitely think that through. The alternate future is one where web assembly modules are just asset modules that default export WebAssembly.Module that somehow is blessed with an origin like a trusted type. |
| 17:49 | <Kris Kowal> | But even in that alternate future, we would want to have module source objects for ESM. The various futures might be equally weird. |
| 17:50 | <Kris Kowal> | I think I would prefer to gamble that WebAssembly be able to participate in the JS module graph eventually. |
| 17:50 | <Kris Kowal> | Because, it clearly can. |
| 17:50 | <Kris Kowal> | Perhaps not without compromise, but it can. |