Open koivunej opened 4 years ago
I've left various comments in the other issues, but at a high level let's aim on having decisions on the following:
tokio
vs async-std
issue. As I mentioned in chat I think we should lean towards fewer dependencies as a first principle.Open question: io_uring
What's the deal? I see two options here.
Edit: Looks like it's option 2 for now!
Made an issue for Dependency Analysis rs-ipfs/rust-ipfs#63 to help us get our head around the tokio vs async-std thing. It seems we're using both
Needs attention of @dvc94ch and @aphelionz and of course anyone else feel free to join.
I am opening up these issues to discuss planning for a longer term future and tactics of
rust-ipfs
and our currentipfs-rust
organization. In case the reader does not know, we have the grant from Protocol Labs to work on rust ipfs implementation.I hope we can decide on the items listed below to help guide us through the work cut out in the grant application and possibly to the future after that:
rust-ipfs
rs-ipfs/rust-ipfs#57rust-ipfs
andipld-daemon
rs-ipfs/_#10rust-ipfs
I've split the three first topics to their own issues and just note here of the about the last one:
Structure of
rust-ipfs
: I think refactoring to workspace/subcrates are possible or might be needed and also tokio/async-std needs to be discussed during design of phase 1.0 deliverables (testing integration). I'd like defer that design dicussion to those issues covering the http api and the http api serving process.Once we get this resolved we should at least link from README to this issue or write up some text there.