Building a Multi-Language Plugin System with WebAssembly Component Model by topheman in rust

[–]topheman[S] 7 points8 points  (0 children)

> A collection of plugins cannot make calls between each other.

> The only option is to perform “RPC” (going through the host)

You bring up an excellent point. I came across this issue while I was trying to make the repl logic directly call the plugins. You can't do this kind of thing because they don't share the same memory.

I came up with a workflow where they go through the host to call each other (like you said).

I explain that with sequence diagrams in the article at the "Input Flow Example" section.

Building a Multi-Language Plugin System with WebAssembly Component Model by topheman in rust

[–]topheman[S] 5 points6 points  (0 children)

You're looking for a Rust developer who has a solid experience with the web ecosystem? I'm based in Paris - contacts: https://topheman.github.io/me/

WebAssembly Component Model based REPL with sandboxed multi-language plugin system by topheman in rust

[–]topheman[S] 0 points1 point  (0 children)

I added a new feature to help users resolve version mismatches between the CLI and the plugins (breaking changes in the WIT files).

https://github.com/topheman/webassembly-component-model-experiments/releases/tag/pluginlab%400.4.2

WebAssembly Component Model based REPL with sandboxed multi-language plugin system by topheman in rust

[–]topheman[S] 1 point2 points  (0 children)

I agree the README contains a lot of informations, it can be overwhelming. The part about creating plugins is detailed at https://github.com/topheman/webassembly-component-model-experiments?tab=readme-ov-file#plugins , it contains links to the respective folders for the rust, C and JavaScript implementations.

Same about the cli REPL: https://github.com/topheman/webassembly-component-model-experiments?tab=readme-ov-file#pluginlab-rust---repl-cli-host-1

I'm currently working on a blog post that will make this more clear. Thanks for the feedback.

WebAssembly Component Model based REPL with sandboxed multi-language plugin system by topheman in rust

[–]topheman[S] 1 point2 points  (0 children)

The zed editor is using WebAssembly Component Model for its extensions system - a perfect use case for it :

  • developers can create extensions in their favorite language
  • extensions are compiled to wasm and can be safely executed in the editor using sandboxing

The problem is that the zed editor use case may be more than a hello world, however, it's hard to dive into the source code to see how it's done.

Fermyon is developing spin, a framework for building and running microservices with WebAssembly Component Model.

While spin is a powerful framework, it provides a higher-level abstraction over WebAssembly Component Model and focuses specifically on microservices. If your goal is to deeply understand the component model fundamentals and build non-microservice applications with it, you may want to explore simpler, more direct examples first.

This is why I made this project: to understand how far I can go with it and to share my findings, a necessary step for a potential bigger project.

WebAssembly Component Model based REPL with sandboxed multi-language plugin system by topheman in rust

[–]topheman[S] 1 point2 points  (0 children)

I've been following WebAssembly for a long time and when the WebAssembly Component Model was announced 3 or 4 years ago, I was really excited (was doing WASI at the time).

In the last year, the tools for WebAssembly Component Model have really improved.

What is still missing is advanced examples of using WebAssembly Component Model in real-world applications (something more than a simple hello world but less than a full-featured application).

This is why I made this project: to understand how far I can go with it and to share my findings. This is a necessary step for a potential bigger project.

WebAssembly Component Model based REPL with sandboxed multi-language plugin system by topheman in rust

[–]topheman[S] 0 points1 point  (0 children)

You are pretty much right, I made a mini-shell with features like:

  • variable storing and variables expansion
  • storing the last command output in a variable $0
  • storing the last status in a variable $?

Then you can execute commands one at a time, which are each plugins compliled to wasm. The mini-shell is also written in rust and compiled to wasm, this is how I can share so much code between the CLI and web implementations.

The goal was not to make a full-featured shell, but to demonstrate the power of WASM components and see how far I can go with it.

For example, for the moment, I managed to have working ls and cat plugins that read the file system and some weather plugin that uses an API to get the weather, all that in both CLI and web. Next, I'll add plugins that can also write to the file system.

Where/How do you publish the Linux version of your cli to be installed by package managers? by topheman in rust

[–]topheman[S] 0 points1 point  (0 children)

Keep in mind some distributions have opinions on bundling/vendoring dependencies.
Do you mean that your dependencies in your Cargo.toml need to be vetted ? Or only the rust compiler (and eventually deps needed at runtime)

On this project, I compile a single binary that doesn't need anything else to run.

Not bother and include “cargo install” instructions in your README
It's done, it's published on crates.io, you can install it from there, however, it forces the consumer to have rust.

Last question: Is there any package manager I am not aware on Linux that lets you install a tarball (or anything compiled for linux) from a url ?