Imports/exports don't match expected Proxy-Wasm ABI versions.

[PiotrSikora]

Hello!

It was pointed out to me (see: proxy-wasm/proxy-wasm-rust-sdk#104) that Proxy-Wasm Go Host doesn't expose all Proxy-Wasm ABI v0.1.0 hostcalls.

Looking at the code, neither imports nor exports match the specification, e.g. host exports proxy_dispatch_http_call and imports proxy_on_plugin_start, but those don't exists in any of the existing versions (ABI v0.1.0, v0.2.0 or v0.2.1).

I believe that the source of the confusion might be the work-in-progress specification for vNEXT in proxy-wasm/spec, although even that doesn't define proxy_on_plugin_start, so it's unclear to me what's the source for your v1 and v2.

Note that there is no documention for either ABI v0.1.0, v0.2.0 or v0.2.1, so the code in Envoy and Proxy-Wasm SDKs is effectively the specification for those versions.

[antJack]

Thanks for the report!

Indeed I also feel quite confused about the exact definition of ABI v0.1.x/0.2.x, since both the envoy and sdk code seem to be inconsistent with the specification.

In terms of cooperation, it might be annoying to tell our partner, who writes the wasm code, to walk through the source code to find the APIs by themselves.

So maybe we should clearly define the accurate ABI list right now? And I'm willing to follow the correct documentation.

[PiotrSikora]

Indeed I also feel quite confused about the exact definition of ABI v0.1.x/0.2.x, since both the envoy and sdk code seem to be inconsistent with the specification.

The current situation is far from perfect, sorry about that! When I origianlly started working on the vNEXT, the assumption was that it would be completed in a few weeks, so we didn't bother documenting ABI v0.1.0 and v0.2.x.

However, since we now have an alternative implementation (thanks!), and vNEXT isn't ready yet, perhaps I should go back and document them... I'll see if I can to do that over the next few days.

In terms of cooperation, it might be annoying to tell our partner, who writes the wasm code, to walk through the source code to find the APIs by themselves.

Are they writing code against the ABI itself, and not using one of the existing SDKs? If so, why?

[antJack]

Sorry for not replying for so long due to a Chinese vacation.

Are they writing code against the ABI itself, and not using one of the existing SDKs? If so, why?

Actually, my partners do not use the existing SDKs directly, they fork from the original Go-SDK and do some modifications for their internal usages. The reason for their modifications mainly comes from

1. the different programming models between Go and C++, e.g., Go does not allow any thread-local, therefore we add the contextID as one of the params for "proxy_get_buffer", etc.
2. the different extension points between MOSN and Envoy. In MOSN we provide some extension points, which are absent in Envoy, therefore we also extend the ABI to adapt those extensions.

Those above modifications are now temporary and experimental for our internal usages, however, I think some of them may be committed to ABI spec in the future, as long as we think it's helpful for improving generality.

Apart from that, I think it's good to reach some milestones/consistencies in the short term, and I'll put some effort on modifying the go-host to make it more consistent with the C++/Rust host.

[codefromthecrypt]

I think the README here should change to say that this is Ant Group's dialect of proxy-wasm based on the state of affairs matching proxy-wasm-go-sdk v0.0.13

It is true that the documentation is incorrect, but the status quo has changed and it is important information for the community to know that this ABI is intentionally incompatible with other things, in order to support Ant Group.

This can help people from wasting time getting involved here only to find out very late nothing can change. cc @taoyuanyuan

For example, you can add a README update like this and close out this issue.

---

Disclaimer

It is understood that this host is incompatible with current proxy-wasm SDKs. This cannot be changed because the ABI in use is required by the primary sponsor of Mosn: Ant Group. Below are known tools that can generate guests compatible with this host:

TinyGo

Build like below with proxy-wasm-go-sdk v0.0.13 which works with TinyGo 0.19.0.

$ tinygo build -o main.wasm -scheduler=none -target=wasi --no-debug -wasm-abi=generic -tags 'abi_010' ./main.go

Note: The maximum version of Go that works with TinyGo 0.19.0 is 1.16.