Stream: general

Topic: "protobuf main" support


view this post on Zulip Soni L. (Sep 14 2024 at 02:11):

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

Inspired by wasm typed main. Contribute to SoniEx2/protobuf-main development by creating an account on GitHub.

view this post on Zulip Soni L. (Sep 14 2024 at 02:30):

(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];)

view this post on Zulip Soni L. (Sep 14 2024 at 02:38):

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.)

Instead of having the classic argc/argv interface which everyone knows and loves, it'd be nice if wasi could provide a typed CLI interface, either using protobuf or some bespoke new thing. Specific...

view this post on Zulip Soni L. (Sep 14 2024 at 02:41):

(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...)

view this post on Zulip Soni L. (Sep 14 2024 at 02:46):

likewise, a native powershell interface would be nice

view this post on Zulip IFcoltransG (Sep 14 2024 at 02:49):

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.

view this post on Zulip Soni L. (Sep 14 2024 at 02:55):

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.

view this post on Zulip Soni L. (Sep 14 2024 at 02:56):

you could just take Actual Paths, instead of trying to guess whether something is an option or a subcommand or a path

view this post on Zulip Ramon Klass (Sep 14 2024 at 12:09):

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

view this post on Zulip Soni L. (Sep 14 2024 at 14:47):

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.

view this post on Zulip Ramon Klass (Sep 14 2024 at 15:10):

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: Dec 23 2024 at 12:05 UTC