David Bryant (Feb 11 2026 at 17:34): David Bryant (Feb 11 2026 at 17:34):Bytecode Alliance Members and Contributors,
We're pleased to invite you to the next installment in our series of ongoing Bytecode Alliance Plumbers Summits, to be held Wednesday and Thursday, February 25 and 26, 2026. This will be an all on-line event supporting full remote participation for anyone anywhere, in three-hour sessions each day that will be recorded so they can be viewed anytime afterward via our YouTube channel. Watch this topic for more information leading up to the event and as a live conversation during the event itself.
Thank you for your support of the Alliance, our projects, and our community! We hope you’ll join us for our next Plumbers Summit!
David Bryant (Feb 12 2026 at 18:35):If you're considering joining us for the upcoming Plumbers Summit we'd welcome your feedback on agenda topics and general participation via a simple form you’ll find here. Thanks!
David Bryant (Feb 18 2026 at 18:01):The planned agenda for next week's Plumbers Summit is now available via our general meeting information repository here. Additional details will be provided both there and here to help you plan for and attend the event.
Bailey Hayes (Feb 19 2026 at 19:16):Make sure you block out your calendars!
Day 1
Day 2
Both calendar events are on the google calendar events@bytecodealliance.org
Note the events calendar for the Bytecode Alliance has a <Copy to my calendar> button.
Screenshot 2026-02-19 at 2.09.48 PM.png
Mendy Berger (Feb 25 2026 at 16:03):Any reason youtube stream not working?
fitzgen (he/him) (Feb 25 2026 at 16:03):@Bailey Hayes youtube stream not working ^
Bailey Hayes (Feb 25 2026 at 16:03):debugging, but zoom believes we are streaming
Alex Crichton (Feb 25 2026 at 16:06):new youtube link: https://www.youtube.com/watch?v=aQchiu6DXUE
fitzgen (he/him) (Feb 25 2026 at 16:08):IIRC zoom uses Wasm to blur backgrounds on the web client
Bailey Hayes (Feb 25 2026 at 16:13):updated agenda page: https://github.com/bytecodealliance/meetings/pull/771
Erik Rose (Feb 25 2026 at 16:42):Seems like parametrized imports would be semantically equivalent to providing some parametrizing module to the imported module. Is the motivation to save the heavyweightness of instantiating a whole 'nother module?
Till Schneidereit (Feb 25 2026 at 16:45):it also has the big benefit of giving a standardized way to expose the parameters, as well as making them statically analyzable
Erik Rose (Feb 25 2026 at 16:46):Earlier access to parametrizing values sgtm!
Chris Fallin (Feb 25 2026 at 16:46):the main benefit to the issue-287 thing to me seems to be the ability to import multiple implementations of the same interface; that's fundamental to composition; I don't think you could polyfill that with runtime string passing or whatnot
Till Schneidereit (Feb 25 2026 at 16:49):I just implemented a system for doing this in content without this kind of parameterization. It works, and isn't terribly heavyweight (one additional core module for the entire composition), but it's far inferior to being able to have wasmtime-wit-bindgen generate bindings that take the parameter as an additional argument explicitly. The routing still has to be done in the composition, but that's entirely fine
Bailey Hayes (Feb 25 2026 at 16:50):From Zulip: :justice: could also be "wasi:redis" and "wasi:memcached"
Bailey Hayes (Feb 25 2026 at 16:50):Right and this works today (well in a non-wasi namespace as those are not part of wasi). It's more for the case of postgres and postgres where it will be different connections/stores to the same interface.
Bailey Hayes (Feb 25 2026 at 16:51):From Joel: I think the idea behind Luke’s example is not so much the difference between a redis-backed store vs. a memcached-backed store as much as it’s about “I need to connect to multiple distinct stores with these names, and if the host can’t provide those specific stores, then it shouldn’t bother running me at all”. There’s currently no way to express that statically.
Chris Fallin (Feb 25 2026 at 16:53):the interesting case that only works statically is if there are different implementations (statically) with the same interface, right? say I want to do a VFS overlay composition component; both filesystems export the same WIT interface but are entirely different code, and we don't want to newtype them with wasi:filesystem1 and wasi:filesystem2 or something like that; and a dynamic-dispatch component pushes the problem one level down (it then needs to link to both composed components). So I think the multiple-of-same-interface-imported thing is actually kind of fundamental at a PL/types level
Bailey Hayes (Feb 25 2026 at 16:56):filesystem is an excellent example. This would allow a single component to have something akin to virtualized volumeMounts without actually having to merge the two or more virtualized filesystems into a single fs.
Till Schneidereit (Feb 25 2026 at 16:58):I agree that that is an interesting case that needs a slightly different approach (or manual dispatch across the different implementations).
I don't think it's the only interesting case for which static analyzability is extremely valuable. In Luke's example, a runtime environment / deployment pipeline can validate that it has the configuration available to satisfy both imports. If instead the id is passed as a dynamic argument, that has to become a runtime check / error, in the worst case post-deployment
Chris Fallin (Feb 25 2026 at 17:00):Oh, agreed, making things static has many benefits in general
Bailey Hayes (Feb 25 2026 at 17:01):Yep agreed. I can think of many, many things we could do with this. It is worth enumerating those so that we can validate them against the design
Alex Crichton (Feb 25 2026 at 18:23):Slides for my presentation (not that it contains links, but in case anyone's curious)
Bailey Hayes (Feb 25 2026 at 18:56):I added links to slides here:
https://github.com/bytecodealliance/meetings/blob/main/plumbers-summit/summit-feb26/README.md#wednesday-february-25
Speakers, feel free to PR in additional materials/slides
David Bryant (Mar 03 2026 at 19:33):A big thank you to everyone for taking part in last week's Plumbers Summit! If you wouldn't mind taking a few minutes to share your thoughts on the event while the experience is still fresh in your mind, here's a hopefully convenient survey: https://docs.google.com/forms/d/e/1FAIpQLSeuBny2i1YoL4ty8TkWkJ9go1v3IL4fXaxyepJKJrVL29e3nA/viewform?usp=publish-editor.
Last updated: Mar 23 2026 at 17:18 UTC