do you think you could add support for the so-called "protobuf main"? it's a very powerful new way to use shell commands: https://github.com/SoniEx2/protobuf-main/blob/default/sayhello/sayhello.c#L18-L36
(yeah, we actually wrote a proof of concept for this thing... it's always exciting when you write code like ptrdiff_t len = argv[argc-1] - argv[1];
)
here's some previous discussion on protobuf main in the context of WASI: https://github.com/WebAssembly/WASI/issues/541 but we'd like to focus this towards protobuf main in the wasmtime CLI. (WASI should use typed main, when that becomes a thing.)
(actually we don't think you can use protobuf main with wasip2 due to a thing called "unicode"? does wasip2 enforce strict unicode strings in argv? we know wasip2 moves away from being posixy, compared to wasip1...)
likewise, a native powershell interface would be nice
As I understand it, the WASI CLI world wouldn't allow arbitrary binary data to be passed in with command line arguments, because WASI strings don't support unpaired Unicode surrogates. This might require a "protobuf-cli" world instead, like how Wasmtime currently supports the wasi-http world alongside wasi-cli.
yeah probably, but that's the WASI side of things, which we don't wanna go into. anyway,
"protobuf main" in wasmtime would be not much different from if wasmtime were to provide a powershell cmdlet. a powershell cmdlet is pretty cool because it solves the main problem with passing CLI arguments to... anything really: the lack of types and the ensuing total confusion between options and arguments.
you could just take Actual Paths, instead of trying to guess whether something is an option or a subcommand or a path
fwiw, the wasmtime cli is already typed, the cli library does type checking during commandline parsing, but your concerns are about exposing those rust types into something other languages can use. WHat you want is already how the rust side works I think
the wasmtime CLI takes an array of strings and then passes it into a parser. this is akin to passing strings to a javascript function which are then eval()'d to produce objects, instead of passing the objects as they are. sure, you need serialization between the caller and callee (because processes in virtual memory can't just pass arbitrary pointers around, besides you'd still need runtime type checking due to the possibility of replacing the executables), but there are better ways to serialize data around than a bespoke untyped DSL that everyone implements differently.
the parser is defined as structs with strong typing is my point, you can run the wasmtime cli function from rust code with typed arguments without using the parser first, and those structs could be used to generate these protobuf bindings you want, but that would be entirely possible outside of wasmtime in a bindings crate, maybe I'm wrong but I don't see this as a feature to add directly to the runtime
Last updated: Nov 22 2024 at 16:03 UTC