Repository navigation
Why import stdio ports, random, wall-clock, timezone ? #789
Description
The http imports world includes things it doesn't use: stdout, random numbers, and unused things from clocks (wall-clock and timezone). Should this be trimmed?
Activity
pchickey commentedon Aug 29, 2025
I think these should not be trimmed, and in fact we should expand these to fit the kind of programs our users need to run.
In in practice we don't have the tooling to compile reasonable guest programs that lack many of these imports. For instance, any program using a libc makes it very difficult to exclude stdin, even if theres no reasonable use of stdin in this world. So, we should allow the import and specify that stdin should always be empty.
In practice all programs that link with libc end up needing the cli environment import, which the proxy world lacks, hence all the tutorials currently say to invoke programs with
wasmtime serve -Scliwhich adds the whole cli world's imports in, a very heavy hammer that includes raw sockets. So, I will advocate we add environment variables into proxy world as part of p3, because its the only way to get runtime config (secrets such as api keys etc) into proxy programs, and again if an embedding really doesn't want to provide it, like stdin its trivial to provide the empty implementation.stdout and stderr are required for debugging. We cannot ship worlds where users can't debug the programs they ship to them.
Required uses for random numbers: seeding a hashmap, selecting a backend for a load balancer.
Required uses for wall clocks: Date header is sent by default in nginx, apache etc, and proxies frequently have to communicate when a cache should expire with a ttl relative to time of insertion or last use
I also suggest we add the wasi-sockets name resolution imports, practical use cases there include load balancers / api gateways which frequently use name resolution to communicate the set of currently healthy hosts.
lukewagner commentedon Aug 29, 2025
As an extra bit of background that might be helpful to understand the current design:
wasi:http/imports) are only meant to beincluded in bigger worlds, worlds likewasi:http/proxyare meant to describe an abstraction of a category of hosts on which whole portable applications can be run (which then logically need things like time and logging).wasi:httpcan contain multiple worlds to describe larger or small sets of supporting hosts and so if we see a use case for defining a distinct class of hosts (bigger or smaller thanproxy) we can define more worlds alongsideproxy. (Expose language, locale, and timezone info #167 is one such example I've been wondering about.) Sinceworlds are "structural" (the name of the targettedworlddoes not appear in the compiled component binary, only the import/export names), we're in a "more the merrier" situation where we don't have to worry about a proliferation of circles in our Venn diagram since structural subtyping lets a component run on any host providing a superset of its imports and expecting a subset of its exports.wingo commentedon Sep 3, 2025
Thanks for the explanations!
Could it be that
wasi:http/importsshould be relatively minimal, butwasi:http/proxywould be relatively full-featured? I.e. that some worlds are just convenient shorthands for "all the interfaces in this package" and some others are "a collection of needed interfaces for a use case". Of course, up to y'all, it just seems to me that e.g. the "world" forwasi:clocks/importsis the least-fixed-point kind, and perhaps it is a pattern to replicate in the other packages.lukewagner commentedon Sep 3, 2025
That's a great point; +1 from me. The
importsworlds is a pattern that sortof emerged to avoid copy-pasting a list of like 10 interfaces, but honestly I think it mostly only is a benefit forwasi:cli/imports(where there are a large number); for almost all other packages there's only a few and so I think it's easier to read (less indirection) to just see the interfaces directly. So maybe we can just nixwasi:http/imports.