Publish a Proxy-Wasm roadmap #74
Conversation
This is sure to be a living document, subject to much discussion. Signed-off-by: Martijn Stevenson <[email protected]>
Signed-off-by: Martijn Stevenson <[email protected]>
Signed-off-by: Martijn Stevenson <[email protected]>
Signed-off-by: Martijn Stevenson <[email protected]>
| * Could benefit NGINX's Lua-based [OpenResty](https://openresty.org/) | ||
| ecosystem | ||
| * (Help wanted) Optimize Rust SDK binary size. It seems compiler dead-code | ||
| elimination is thwarted by the use of Context traits. |
There was a problem hiding this comment.
Self AI: file issues where missing, especially this one which needs context/details
| (envoyproxy/envoy#36996). Documentation, security scanning, tests, bug | ||
| fixes, etc. | ||
| * (TBD: @mpwarres) Implement the v0.3 Proxy-Wasm ABI. | ||
| * (Help wanted) Decouple from the thread-local execution model. As wasm |
There was a problem hiding this comment.
I am very interested in this, as it has a significant meaning. If I understand correctly, it allows wasm modules to run an event loop in a separate thread without blocking the Envoy worker threads. This makes it possible to reuse native IO-related libraries from Go/Rust/... SDKs (such as HTTP/Redis/MySQL).
@martijneken @mpwarres Will we set achieving this capability as a work goal for this task?
| map to components? | ||
| * What are the API gaps? How should we evolve Proxy-Wasm to become | ||
| WASI-compatible? What are good incremental steps? | ||
| * Are there any performance gaps? |
There was a problem hiding this comment.
@martijneken FYI, it's by no means a ready solution, but I started playing with some kind of shim that converts proxy-wasm plugin into WASI. In the ideal world, in the future once it's more or less ready, we can just use it to build a proxy-wasm plugin code into a wasi-http proxy component. The goal is to smooth migration from proxy-wasm to WASI by providing some level of backward compatibility for existing proxy-wasm code.
If you think it's interesting, you can find work in progress in https://github.com/krinkinmu/wasi-http and I'm happy to hear any feedback you may have on the approach and on the details of implementation as well.
|
This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here! |
|
It is suggested to add this goal: enhance the security of doAfterVmCallActions, as the current mechanism may lead to unexpected calls on the Host side, resulting in envoy crash(refer to proxy-wasm/proxy-wasm-cpp-host#326). |
There was a problem hiding this comment.
Two high-level comments:
- While I agree that we need to publish a (high-level) roadmap, a lot of items here (especially for the host and Envoy integration) are effectively implementation issues that should be tracked in the issue tracker and not here.
- This roadmap completely ignores hosts other than Envoy, so it would be great to rewrite some of those issues into proxy-agnostic way (where applicable, but see above).
| @@ -14,7 +14,10 @@ Proxy-Wasm extensions across different proxies. | |||
|
|
|||
| The latest and widely implemented version of the specification is [v0.2.1]. | |||
|
|
|||
| The envisioned evolution for Proxy-Wasm is described in the [roadmap]. | |||
There was a problem hiding this comment.
This is more of a "short term roadmap" than "evolution".
| [v0.2.1]: abi-versions/v0.2.1/README.md | ||
| [roadmap]: docs/Roadmap.md | ||
|
|
||
| ## Implementations | ||
|
|
There was a problem hiding this comment.
Nit: slight preference for putting this in ROADMAP.md for easy discovery and to align with other files in this repo.
| * Align this repository with the vision of WebAssembly: a portable technology | ||
| that is cross-language, cross-platform, and cross-provider. | ||
|
|
||
| <a name="abi"></a> |
There was a problem hiding this comment.
FYI, section links are automatically generated, so this isn't necessary (here and in other places).
| * [Spec / ABI](#abi) | ||
| * [SDKs / language support](#sdks) | ||
| * [Host features](#host) | ||
| * [Envoy integration](#envoy) |
There was a problem hiding this comment.
Nitpicking, but this is different style * vs - and 3 spaces vs 1 space than other files (e.g. CHANGELOG.md) in this repo.
| * (Q1'25: @piotrsikora, @mpwarres) Publish ABI v0.3, containing at least: | ||
| * Feature negotiation (proxy-wasm/spec#71 and proxy-wasm/spec#56) | ||
| * Better header/body buffering support (proxy-wasm/spec#63) | ||
| * Async shared data (proxy-wasm/spec#54) |
There was a problem hiding this comment.
Per discussion elsewhere, I think this might be better suited as the first feature extension.
| * How do | ||
| [Proxy-Wasm interfaces](https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/main/include/proxy-wasm/context_interface.h) | ||
| map to components? |
There was a problem hiding this comment.
The ContextInterface is an interface between Proxy-Wasm C++ Host and proxies embedding it, it's not a Proxy-Wasm interface.
| * (Help wanted) Evaluate uses of foreign functions to identify feature gaps. | ||
| * For example, Envoy | ||
| [registers foreign functions](https://github.com/search?q=repo%3Aenvoyproxy%2Fenvoy%20RegisterForeignFunction&type=code) | ||
| for signature checking, compression, filter state, route cache, and CEL | ||
| expressions. | ||
| * Are there similar extensions in Nginx? Apache Traffic Server? | ||
| * Which of these features should be promoted to ABI interfaces? |
There was a problem hiding this comment.
Most (all?) all of them should be included in Proxy-Wasm specification, definitely those that make sense across multiple implementations.
The question is what are the trade-offs for keeping them as optional registered FFIs (#71) vs native ABIs?
| * (Help wanted) Stop using Emscripten in the C++ SDK. Instead use Clang / | ||
| wasi-sdk (proxy-wasm/proxy-wasm-cpp-sdk#167). | ||
| * (Help wanted) Merge LeakSignal's | ||
| [proxy-sdk](https://crates.io/crates/proxy-sdk) crate into the Rust SDK. |
There was a problem hiding this comment.
Those two are low-level implementation details with existing issues, so I'm not sure if there is any value in putting it here? We probably don't want to turn this file into an issue tracker.
| * Could benefit NGINX's Lua-based [OpenResty](https://openresty.org/) | ||
| ecosystem | ||
| * (Help wanted) Optimize Rust SDK binary size. It seems compiler dead-code | ||
| elimination is thwarted by the use of Context traits. |
There was a problem hiding this comment.
Same as above (this should be an issue in Rust SDK, not a roadmap item).
| * (Help wanted) Expand the use of SharedArrayBuffer to reduce memcpy into wasm | ||
| runtimes. This is especially promising for HTTP body chunks. See relevant | ||
| [WASI issue](https://github.com/WebAssembly/WASI/issues/594). Also reduce | ||
| [binary memcpy](https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/21a5b089f136712f74bfa03cde43ae8d82e066b6/src/v8/v8.cc#L272). |
There was a problem hiding this comment.
This is slightly more complicated than it initially appears... Supporting this and eliminating copies would require host (including it's modules/extensions) to read/write data from/to the network to/from memory shared with WasmVM, which is linear memory block that needs to be pre-allocated upfront.
Share in-flight efforts and outline the next high-priority features.
This PR is a request for comment. Please tell us what's missing!