Archiving cap-std

Không có tệp, bài kiểm thử hoặc entry point nào được nêu tên, và issue yêu cầu các câu hỏi hoặc mối quan ngại thay vì một tác vụ triển khai được xác định. Trước tiên, hãy đọc kế hoạch di chuyển và lưu trữ; việc hoàn thành không được nêu rõ đối với một đóng góp độc lập.

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.