Gateway uses minimal IPFS Core API

[ghost]

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.

• (Disregard the first commit, it'll be rebased out once gateway: clean up its surface, and remove BlockList #2874 is merged.)
• 5e328bf starts a CoreAPI interface offering Cat() and Ls() alongside data structures and errors, as well as an implementation thereof.
• 8b6cf07 starts using the rump Core API for serving GET requests in the gateway.

A possible direction forward:

• The package 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.
• The package go-ipfs-core-api implements go-ipfs-core-api/interface backed by a proper IpfsNode. It depends on a lot of go-ipfs internals, like core, merkledag, unixfs/io.
• The existing package go-ipfs-api implements go-ipfs-core-api/interface backed by the API Server.
• go-ipfs/core/commands uses go-ipfs-core-api -- most of the logic there should live in the core-api.
• The gateway, FUSE, and whatever else there is also use either go-ipfs-core-api or go-ipfs-api.

[Kubuxu]

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 Ls with ReadDir, it is clearer, references readdir from C STD lib and more established.

[ghost]

We already have a Core API layed out though: ipfs/specs#85

How would these relate to each other?

[Kubuxu]

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.

[qxotk]

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.

[whyrusleeping]

why do we need to rebind the path type?

[ghost]

yep should be an interface instead -- I made a WIP commit while switching computers

[daviddias]

@lgierth @Kubuxu have you seen https://github.com/ipfs/interface-ipfs-core ?

[ghost]

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.

[daviddias]

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 :)

[ghost]

Closing in favor of #3207