Publish a Proxy-Wasm roadmap

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?

[martijneken]

Share in-flight efforts and outline the next high-priority features.

This PR is a request for comment. Please tell us what's missing!

[johnlanni]

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?

[martijneken]

Huh interesting point. AIUI proxy-wasm already has some support for scheduling work (e.g. event callbacks, timers, shared queues), but I think it all ends up back on the calling VM thread or the Envoy main thread (via singletons).

Our interest was mostly about decoupling wasm CPU (so running wasm doesn't block Envoy threads) and limiting overheads (little-used plugins don't need a VM per Envoy worker thread). So we imagined a similar model as today (streams/requests sticky to independent threads), but a manager component that scales each plugin's threads up/down dynamically. The major risk in all of this is blowing up CPU/NUMA cache locality and incurring CPU scheduling overhead.

IIUC you'd like to take it further and give the wasm runtime access to a shared thread pool? This would require new primitives for scheduling work and/or launching threads?
https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-threading-built-ins

This would be very interesting to discuss in the next community meeting.

[krinkinmu]

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

[martijneken]

Awesome! Added a link here.

[mikemorris]

This whole roadmap is really exciting, appreciate the effort in compiling all these initiatives and excited to make some progress here!

[johnlanni]

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

[PiotrSikora]

Two high-level comments:

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

[PiotrSikora]

This PR should be moved to the community repo, now that we have it.

[PiotrSikora]

I'm not sure why this is linked here?

[PiotrSikora]

This is unlikely to ever work, without host being specifically architected to read data from the network directly into Wasm's linear memory block.

AFAIK, the "multiple memories" proposal doesn't allow to attach / detach memories on-the-fly.

[oschaaf]

drive-by comment - I would love this as an option, but I'm not sure I would love it as a one-size-fits-all due to the concerns mentioned. Thinking out loud; I wonder if the problem could be addressed by offering the decoupling as an api to modules instead, something along the lines of that modules could opt in to posting work on a threadpool (and register for completions or some such)?