You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fastly has official support for Rust, and beta support for AssemblyScript. I think it'd be interesting to have a spec test which can run against wasm binaries produced by both source languages. Coincidentally, this could also be used by anyone developing their own guest bindings for other languages.
My idea is to have a series of defined endpoints, one for each test, where (ideally) each test isolates to a minimal subset of the ABI. There would be a corresponding implementation of these endpoints for each source language. Implementations could write a response with a specific status code as the default response to indicate that a particular test isn't implemented.
For example, there could be a test for dictionaries. Implementations would provide handlers for /dictionaries that are supposed to open a specific dictionary, get a key, and return the value of that key. If a particular implementation does not yet have dictionary support, it could instead write back a 501 Not Implemented to signal to the test runner that it should be skipped.
The text was updated successfully, but these errors were encountered:
I think I'm going to work on this next. I'd like to bring in an AssemblyScript guest program for tests and having a "standard" test suite will be nice, distinct from an example wasm program.
Fastly has official support for Rust, and beta support for AssemblyScript. I think it'd be interesting to have a spec test which can run against wasm binaries produced by both source languages. Coincidentally, this could also be used by anyone developing their own guest bindings for other languages.
My idea is to have a series of defined endpoints, one for each test, where (ideally) each test isolates to a minimal subset of the ABI. There would be a corresponding implementation of these endpoints for each source language. Implementations could write a response with a specific status code as the default response to indicate that a particular test isn't implemented.
For example, there could be a test for dictionaries. Implementations would provide handlers for
/dictionaries
that are supposed to open a specific dictionary, get a key, and return the value of that key. If a particular implementation does not yet have dictionary support, it could instead write back a 501 Not Implemented to signal to the test runner that it should be skipped.The text was updated successfully, but these errors were encountered: