You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 21, 2020. It is now read-only.
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 current ipfs-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:
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.
The text was updated successfully, but these errors were encountered:
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 HTTP v0 API for testing rust-ipfs#60
The 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.
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
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.
The text was updated successfully, but these errors were encountered: