Archiving cap-std

cap-std was originally built for the purpose of implementing the original vision for wasi-filesystem, for Wasmtime. Since it was first launched, we've learned several lessons.

One of the big ones was that the whole preopens design in wasi-filesystem and the `RESOLVE_BENEATH` filesystem semantics, that cap-std implements, and that were inspired by CloudABI and Fuchsia, have not turned out to be worthwhile for wasi-filesystem. They're too different from the kinds of filesystem APIs that the vast majority of developers and existing code are expecting. And at the same time, they're not different enough to deliver sufficiently compelling advantages for WASI's use cases. I believe there is now broad consensus to migrating wasi-filesystem to a different style of filesystem semantics. There are still some open questions about exactly how that will work, but in any case, I expect there will be a need to change the implementation code in a way that wouldn't make sense for cap-std as we currently know it.

Also, maintaining cap-std as an independent library has turned out to make the code more complex to maintain, because it has meant that wasi-filesystem semantics were awkwardly split, with part being handled by code in Wasmtime and part by code in cap-std.

And, just having two repositories instead of one made things like security updates more complex, because we have to release cap-std packages separately from Wasmtime packages.

So, the plan is to vendor the parts of cap-std's code that Wasmtime needs into the Wasmtime tree directly, no longer published as an independent library. With that, the Bytecode Alliance doesn't have a need for maintaining the independent cap-std repository anymore, so I'm considering marking the repository as archived.

But before I make any changes, I'm happy to answer any questions or concerns anyone might have here.

ファイル、テスト、またはエントリポイントは指定されておらず、issue では定義された実装タスクではなく質問や懸念が求められています。まず移行およびアーカイブ計画を読んでください。独立したコントリビューションについて、完了は指定されていません。

索引モデルが issue の本文から書いたものです。