docs: update architecture overview and core architecture image, add more info to the readme #637
Conversation
…ore info to the readme
daviddias
force-pushed
the
feat/arch-diagrams
branch
from
78dc5fc
to
9a69a12
Compare
| ├── cli # Implementation of the IPFS CLI | ||
| │ └── ... | ||
| ├── http-api # The HTTP-API implementation of IPFS as defined by http-api-spec | ||
| ├── core # IPFS implementation, the core (what gets loaded in browser) |
There was a problem hiding this comment.
@diasdavid these really should be three different modules at this point
There was a problem hiding this comment.
Almost entirely agree with the caveats of:
- This forces us to run the 5 sets of tests every time
- It gets a way to people install js-ipfs as they are used to do it with go-ipfs (install one thing, get it all)
There was a problem hiding this comment.
My idea was to have js-ipfs (ipfs npm module) be a tiny wrapper that exposes the same functionality as it does now for end users. But code and tests would move into
- js-ipfs-core
- js-ipfs-cli
- js-ipfs-http
This way you get the same convenience but if you only want to use js-ipfs in the browser all you need is to install js-ipfs-corewithout all the cli + http baggage.
There was a problem hiding this comment.
I understand, let's get to js-ipfs 1.0.0 first, then we factor out :)
There was a problem hiding this comment.
Is there a plan on what we need for 1.0.0? Why should we do a big change of code structure after 1.0, for me it makes much more sense to do it before that.
@pgte hope this is useful to you :)