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
core/coreapi/coreapi.go
Outdated
| context "gx/ipfs/QmZy2y8t9zQH2a1b8q2ZSLKp17ATuJoCNxxyMFG5qFExpt/go-net/context" | ||
| ) | ||
|
|
||
| type Path path.Path |
There was a problem hiding this comment.
why do we need to rebind the path type?
There was a problem hiding this comment.
yep should be an interface instead -- I made a WIP commit while switching computers
|
@lgierth @Kubuxu have you seen https://github.com/ipfs/interface-ipfs-core ? |
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 <larsg@systemli.org>
License: MIT Signed-off-by: Lars Gierth <larsg@systemli.org>
|
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/interfaceprovides 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-apiimplementsgo-ipfs-core-api/interfacebacked by a proper IpfsNode. It depends on a lot of go-ipfs internals, likecore,merkledag,unixfs/io.go-ipfs-apiimplementsgo-ipfs-core-api/interfacebacked by the API Server.go-ipfs/core/commandsusesgo-ipfs-core-api-- most of the logic there should live in the core-api.go-ipfs-core-apiorgo-ipfs-api.