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
NOTE: I don't intend to start a big discussion around this, as I think 1) is relatively low risk, 2) is pretty self evident. This is mostly a brain dump after taking an initial stab at it - but feedback is welcome as I want to make sure I don't miss something obvious either.
Here are some questions that have come up after starting this effort:
ipfsd-ctl execs the Go executable and communicates with it over cli (this is natural since it's not a node proces)
In order to integrate node ipfs support, we have two options
Usejs-ipfs cli
The advantage is that we can reuse a lot (how much?) of it the current implementation
The disadvantage is that there are differences which could invalidate reusing the current implementation - I feel like until we dig in, we won't have a clear understanding
Use js-ips as a library
The advantage is that it's a lot simpler to interact with js-ipfs over the library interface
The disadvantage is that we implement it from scratch - tho we can pull/copy existing implementations of this from the various available out there
using ipfsd-ctl now becomes context aware
if ran from within js-ipfs we must likely want the option to use that js-ipfs, this will allow us to test it against itself running as a standalone node.
if ran from any other project or standalone, just use the bundled js-ipfs
IRC discussion for background:
09:55 <@dryajov> daviddias: victorbjelkholm: you around? want to bounce a few ideas of you for the ipfsd-ctl stuff…
09:55 <@victorbjelkholm> yup!
09:56 <@dryajov> basically, for the js daemon, do we want to spawn an external process a la Go? or use the ipfs library directly (basically reusing the factory stuff in js-ipfs)
09:57 <@dryajov> I think it comes down to, which interface is going to be more consisten/stable - cli or library?
09:58 <@dryajov> thats one thing… #2 is:
09:58 <@victorbjelkholm> #1:
09:59 <@victorbjelkholm> could spawn it directly in the process, as long as we expose the http-api so js-ipfs-api will be used for both js-ipfs and go-ipfs, so we can be 100% interface works the same
10:03 <@dryajov> hmm, your right… http-api will give us a consistent interface either way (I was thinking more from ipfsd-ctl internals perspective tho, but voising it out kinda makes the choise obvios :D - library is way easier to use)
10:03 <@dryajov> your right, http-api will give us a consistent interface either way
10:03 <@dryajov> 👍
10:04 <@dryajov> #2: running inside js-ipfs vs running standalone
10:04 <@dryajov> if running from js-ipfs we want to use _that js-ipfs_
10:05 <@dryajov> if running from outside, we just require the bundled one?
10:06 <@dryajov> victorbjelkholm: does #2 make sense, I can elaborate if its too confusing - brain dump at this point
10:12 <kyledrake> hsanjuan let me know when you're ready for me to take a wrecking ball to ipfs-cluster. :)
10:13 <@victorbjelkholm> dryajov: hm, thinking about the internals, way easier to skip the library and spin up process, then it doesn't matter if it's go/js/rust/scheme
10:14 <@victorbjelkholm> then #2 would always run bundled one
10:14 <@victorbjelkholm> the daemon for each language should be as a optionalDependency as well, as you might only use go-ipfs for example
10:23 <@dryajov> victorbjelkholm: hehe… my dilema...
10:23 <@dryajov> for #1
10:23 <@dryajov> tho, we still have differences from go to js cmd and outputs
10:24 <@dryajov> so we can’t reuse %100, but it should be close enough
10:24 <@victorbjelkholm> yeah, but the startup/shutdown sequence should be the same (ipfs init, ipfs daemon)
10:24 <@victorbjelkholm> the outputs should be standarized at one point as well (maybe we need ipfs-interface-cli)
10:28 <@dryajov> +1 for ipfs-interface-cli...
Right now, 3/4 are done. I understand your point that there are differences in the CLI, but that is ok, the first Milestone is to get the interaction through the ipfs-api to work just fine. Anything that is not supported (namely by js-ipfs) will error and the user will be informed (which is fine).
NOTE: I don't intend to start a big discussion around this, as I think 1) is relatively low risk, 2) is pretty self evident. This is mostly a brain dump after taking an initial stab at it - but feedback is welcome as I want to make sure I don't miss something obvious either.
Here are some questions that have come up after starting this effort:
ipfsd-ctl
exec
s the Go executable and communicates with it overcli
(this is natural since it's not a node proces)js-ipfs
clijs-ipfs
over the library interfaceusing ipfsd-ctl now becomes context aware
js-ipfs
we must likely want the option to use thatjs-ipfs
, this will allow us to test it against itself running as a standalone node.js-ipfs
IRC discussion for background:
@victorbjelkholm @diasdavid
The text was updated successfully, but these errors were encountered: