x/wasihttp: add wasihttp package

[Mossaka]

This commit ports the wasihttp package from the wasi-http-go repository to here under the x/wasihttp directory. The wasihttp package provides a WASI HTTP server and client implementation using Go net/http package.

The ./x/wasihttp/internal directory is regenerated using make go-bindings command from the wasihttp Makefile. Examples can be found in the x/wasihttp/examples directory and can be run under the ./x/wasihttp working directory.

This new package has its own CHANGELOG.md, README.md, and RELEASE.md files to document the changes, usage, and release notes.

Signed-off-by: Jiaxiao Zhou [email protected]

[ydnar]

Can we have this share WIT files with the files in testdata?

[ydnar]

Should this have its own go.mod file if it has its own CHANGELOG?

[Mossaka]

@ydnar I thought testdata is for testing purposes With that said, why do you want to share the WIT files in x/wasihttp with testdata?

[LiamRandall]

Nice work on this one @Mossaka!

[ydnar]

This PR highlights a bug (or a feature, depending on how you look at it) of wit-bindgen-go that I think we should address before merging: unnecessary, duplicative code generation.

TinyGo’s stdlib already includes the generated bindings for wasi:cli/command. The only reason they’re generated again is because the proxy WIT includes wasi:cli/command. Package wasihttp does not need the full CLI world, except for testing, and does not import the generated code.

I’d like to propose a feature for wit-bindgen-go to limit the generated code to a specific WIT package (or world or interface), so the generated bindings in x/wasihttp/internal are more narrowly scoped to what’s necessary to implement wasi-http.

[elewis787]

This PR highlights a bug (or a feature, depending on how you look at it) of wit-bindgen-go that I think we should address before merging: unnecessary, duplicative code generation.

TinyGo’s stdlib already includes the generated bindings for wasi:cli/command. The only reason they’re generated again is because the proxy WIT includes wasi:cli/command. Package wasihttp does not need the full CLI world, except for testing, and does not import the generated code.

I’d like to propose a feature for wit-bindgen-go to limit the generated code to a specific WIT package (or world or interface), so the generated bindings in x/wasihttp/internal are more narrowly scoped to what’s necessary to implement wasi-http.

@ydnar I am interested in following along on this.

I would add that when developing libraries that intend to wrap imports and exports off shared interfaces, there are also conflicts in generating code. This is not directly related, but it is something I've been attempting to resolve. Happy to write a separate issue for this explaining what I think is the conflict.

[Mossaka]

I’d like to propose a feature for wit-bindgen-go to limit the generated code to a specific WIT package (or world or interface), so the generated bindings in x/wasihttp/internal are more narrowly scoped to what’s necessary to implement wasi-http.

Sounds good to me. I've limited the generated code to this specific WIT world:

world proxy {
	import wasi:clocks/monotonic-clock@0.2.0;
	import wasi:io/streams@0.2.0;
	import wasi:io/error@0.2.0;
	import wasi:io/poll@0.2.0;

	import wasi:http/types@0.2.0;
	import wasi:http/outgoing-handler@0.2.0;
	export wasi:http/incoming-handler@0.2.0;
}

it's much more narrowly scoped than before and wasi:clocks and wasi:io are the only necessary packages that wasi:http/types interface depends on.

[Mossaka]

@ydnar please take a look and let me know your thoughts on how to proceed with this PR