TC39 Module Harmony
2023-05-10
plaintext logs
prev next
source on github
16:30
<littledan>

We reviewed the modules presentations internally in Bloomberg. Some feedback which might be useful, especially for Luca and Guy's presentation:

  • Consider explaining that the idea is to come back and add JS module source later (which will probably be a question that has most people left hanging)
  • If this comes before Nicolo's presentation, it should reference the later one, and specifically call out the concept that we have this interdependent space that the modules group has worked out to some extent, and we'd like to land these things piecemeal such that each stands on their own but they work together well, and it wouldn't be so bad if we actually didn't follow through on the later ones.
  • In general, where possible, anticipate people's concerns and acknowledge them, or explain answers to questions about cross-cutting concerns (at least with reference links) rather than trying to gloss over things and just explaining the positive aspects.
  • The modules group isn't working like Intl since we're having trouble engaging implementers, especially browsers. We should probably organize a specific set of meetings with them, to talk through the space in general and their possible implementation concerns.
17:26
<Kris Kowal>
@room On the SES call today, Daniel Ehrenberg suggested we have a dedicated engagement with implementers to surface VM specific module harmony concerns. I’m looking for contacts to volunteer for such a meeting so we can send out a doodle.
17:28
<dminor>
Please invite me and I'll pass it along to some SpiderMonkey folks who are working on module stuff.
17:28
<dminor>
I'll show up too, of course :)
17:35
<shu>
Kris Kowal: send me an invite but i don't have that many cycles to spare. i'd like relatively infrequent and very targeted with concrete questions in the agenda?
17:38
<Kris Kowal>
Kris Kowal: send me an invite but i don't have that many cycles to spare. i'd like relatively infrequent and very targeted with concrete questions in the agenda?
That can be arranged. We can put such a thing together on the module harmony calls leading up.
17:39
<Kris Kowal>
We can also ask the XS folk to show us where they found challenges in their implementation of Compartments.
17:39
<Kris Kowal>
Since Compartments capture most of the layers of module harmony.
17:41
<Kris Kowal>
The piece of feedback we’ve already received is that virtualizing modules led to the discovery of existing bugs in their module internals, since those behaviors could then be excited by fuzzing.
17:43
<Kris Kowal>
cc phoddie (Peter Hoddie) re implementer show and tell for module harmony.
17:44
<shu>
well and you have my longstanding feedback, that i am, in general, against exposing previously un-user code exposed things to user code
17:47
<littledan>
well and you have my longstanding feedback, that i am, in general, against exposing previously un-user code exposed things to user code
This is a pretty broad statement! We should probably talk in a more detailed way about what these things apply to.
17:47
<shu>
yes indeed
17:49
<littledan>
Kris Kowal: send me an invite but i don't have that many cycles to spare. i'd like relatively infrequent and very targeted with concrete questions in the agenda?
The idea is that this would be one-time (or maybe repeated but that's a future discussion) and that it'd try to go over the whole set of proposals. The question is generally, "does this seem bad to you? why?" The thing is, the people championing modules proposals already have a lot worked out among them(/us), and the need from here is to identify blockers/what we shouldn't do from that plan.
17:49
<shu>
ah, one time! perfect
17:49
<Kris Kowal>
Very cognizant of that general position. My understanding is that the issues that XS encountered consisted of behaviors that were previously excitable, but not discoverable with a fuzzer.
17:50
<shu>
then it sounds like you should give us some reading material ahead of time to develop positions ahead of time
17:50
<shu>
otherwise ISTM we'll need at least two meetings, one for us to understand what's concretely being asked with clarifications, then one to give harder-line positions
17:51
<littledan>
I'm not sure if that latter thing would be so bad (maybe the second part sharing positions could be async?) since as much as we write, it probably won't answer all of your questions.
17:54
<shu>
yeah a bounded number of meetings for small N sgtm