As I prepare to change projects I'm working on, I decided to review this repository for archiving &emdash; I believe we should archive it. Here's why:
- the AssemblyScript bindings here have been unmaintained for some time
- the Rust bindings here have fallen out of date with the latest specification of wasi-nn
- keeping this up-to-date is a chore that no one wants to take on because...
- the best way to generate and use bindings for any WASI proposal is with
wit-bindgen
- this repository requires a bunch of extra work to fix CI, update examples, clean up unused parts, etc.
Some background: back when wasi-nn was first specified with WITX, it was difficult to access the low-level specification APIs. In that world, it made sense to generate the low-level, unsafe bindings to languages like Rust and AssemblyScript and then wrap them with a higher-level API that made it all more developer-friendly. Since then, the adoption of WIT as the IDL for WASI proposals and improvements in tooling (i.e., wit-bindgen) make this "generate and wrap" idea outdated. E.g., in #108 you can see how redirecting users to wit-bindgen is the right approach.
In the past, I kept this alive due to community requests but I will no longer have time to do so. I think now is the right time to archive this project and direct future developers towards wit-bindgen. Here's how I propose to do this:
As I prepare to change projects I'm working on, I decided to review this repository for archiving &emdash; I believe we should archive it. Here's why:
wit-bindgenSome background: back when wasi-nn was first specified with WITX, it was difficult to access the low-level specification APIs. In that world, it made sense to generate the low-level,
unsafebindings to languages like Rust and AssemblyScript and then wrap them with a higher-level API that made it all more developer-friendly. Since then, the adoption of WIT as the IDL for WASI proposals and improvements in tooling (i.e.,wit-bindgen) make this "generate and wrap" idea outdated. E.g., in #108 you can see how redirecting users towit-bindgenis the right approach.In the past, I kept this alive due to community requests but I will no longer have time to do so. I think now is the right time to archive this project and direct future developers towards
wit-bindgen. Here's how I propose to do this:wit-bingeninstead" messagemain