aphelionz
commented
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:
- ~"Workspacing" the repo - I think this should be OK but we should take care and identify any risks before attempting~ Will be resolved in rs-ipfs/rust-ipfs#60
- The
tokiovsasync-stdissue. 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.
- Try to support it, using something found here or maybe here
- Wait until somebody else does it / maybe already has done it in one of the above links by now
Edit: Looks like it's option 2 for now!
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-ipfsand our currentipfs-rustorganization. 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-ipfsrs-ipfs/rust-ipfs#57rust-ipfsandipld-daemonrs-ipfs/_#10rust-ipfsI'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.