-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Gateway uses minimal IPFS Core API #2876
Conversation
So my plan for core-api is to one-to-one map it to RPC API and totally separate it from go-ipfs (and js-ipfs). That is why the API itself should be simple, follow procedure call pattern. It would be great if we could work with js-ipfs on it. Naming suggestion: replacing |
We already have a Core API layed out though: ipfs/specs#85 How would these relate to each other? |
There isn't much in terms of specs there (and I don't know how much js team has done on it). I think we shouldn't repeat CLI API scheme (we already have working API like that) and design something extremely simplistic. It is my view on the matter when it comes to creating and implementing new API as we already have quite complex API which isn't simple to implement / write down in different implementation. |
Perhaps the spec differs from ipfs-api in writing style and audience? The spec might be more prose and expose reasoning and api could be terse details using exact language of arguments and returns. |
0cf8bb8
to
aa6dec1
Compare
context "gx/ipfs/QmZy2y8t9zQH2a1b8q2ZSLKp17ATuJoCNxxyMFG5qFExpt/go-net/context" | ||
) | ||
|
||
type Path path.Path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need to rebind the path type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep should be an interface instead -- I made a WIP commit while switching computers
Yes -- what's your question? :) We can make that repo hold both js- and go- interfaces, and go-ipfs-api and go-ipfs-core-api hold the implementations. |
Just making sure it wasn't missed :) It think that if we can have a spec document that works for both, it would be great :) |
35c8b67
to
e02fc54
Compare
License: MIT Signed-off-by: Lars Gierth <[email protected]>
License: MIT Signed-off-by: Lars Gierth <[email protected]>
License: MIT Signed-off-by: Lars Gierth <[email protected]>
Closing in favor of #3207 |
This is a follow-up to ipfs/specs#85, which discusses an IPFS Core API. The immediate goal is to slim down the surface area between the gateway, and go-ipfs internals, so that the gateway can easily be extracted into its own package.
Cat()
andLs()
alongside data structures and errors, as well as an implementation thereof.A possible direction forward:
go-ipfs-core-api/interface
provides interfaces, data structures, and errors. Tools like ipget or pinbot can choose between implementations backed by the API server (:5001), or by a proper embedded IpfsNode.go-ipfs-core-api
implementsgo-ipfs-core-api/interface
backed by a proper IpfsNode. It depends on a lot of go-ipfs internals, likecore
,merkledag
,unixfs/io
.go-ipfs-api
implementsgo-ipfs-core-api/interface
backed by the API Server.go-ipfs/core/commands
usesgo-ipfs-core-api
-- most of the logic there should live in the core-api.go-ipfs-core-api
orgo-ipfs-api
.