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.

Aucun fichier, test ou point d’entrée n’est nommé, et l’issue demande des questions ou des préoccupations plutôt qu’une tâche d’implémentation définie. Lisez d’abord le plan de migration et d’archivage ; l’achèvement n’est pas spécifié pour une contribution indépendante.

Rédigé par le modèle d'indexation à partir du texte de l'issue.