-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of ipfd-ctl (for consideration) #149
Labels
P1
High: Likely tackled by core team if no one steps up
Comments
daviddias
added
status/ready
Ready to be worked
P1
High: Likely tackled by core team if no one steps up
and removed
status/deferred
Conscious decision to pause or backlog
labels
Oct 17, 2017
Can this be closed? |
Sure :) It's not urgent anymore |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Taken from: ipfs/js-ipfs#556 (comment)
Satelite modules ipfsd-ctl vs ipfs-daemon vs ipfs-factory
We need a thing that lets us spawn nodes (js-ipfs and go-ipfs) easily, so that apps like orbit, our tests and benchmarks can switch between different combinations (js-ipfs, js-ipfs daemon + js-ipfs-api, go-ipfs + js-ipfs-api) without too much configuration.
This endeavor doesn't have to be part of "Improving Init", but it would be definitely useful to a lot of contributors, users and even for our testing.
Currently, we have:
ipfsd-ctl - spawns go-ipfs daemons and returns a js-ipfs-api instance to talk with them
ipfs-factory (not a module, just a tool within this repo) - spawns daemons from Node.js and the Browser.
ipfs-daemon - https:/haadcode/ipfs-daemon
ipfsd-ctl is the one that has more adoption.
The text was updated successfully, but these errors were encountered: