core/coreapi package extracted to interface-ipfs-core repo

[ghost]

See ipfs-inactive/interface-js-ipfs-core#66

Dependencies:

• Gateway uses minimal IPFS Core API #2876 Gateway uses minimal IPFS Core API
  • for the basic Core API imeplementation

[whyrusleeping]

@lgierth update here?

[Mr0grog]

Moving a relevant conversation here from ipfs-inactive/docs#68…

@Mr0grog:

The “JS & Go Libraries” section that links to the ipfs/interface-ipfs-core docs really only covers the JS library. It appears as though it was intended to cover Go, too, but what I’ve uncovered from asking around is that many folks aren’t actually working towards that, let alone are even sure it totally makes sense…

…If the Go bits are never really going to be documented in the interface docs, we should be clear about that and remove all the references to Go. We should also figure out if this is the best way to document that API rather than just test it.

@olizilla:

Can we fix that? Who do we need to convince @diasdavid @whyrusleeping?

@magik6k:

Yep, coreapi is what will eventually be the 'go part' of interface-ipfs-core. Currently coreapi lives in go-ipfs repo because it's easier to develop it there. The roadmap is in #4498

To add a little more context, I was told in a few private conversations that documenting the Go CoreAPI in interface-ipfs-core was unlikely to really happen because:

• The effort is going super slow
• It’s unlikely to exactly match JS or the “commands” (in the CLI/HTTP sense). For example, it exports additional utilities like ResolveNode(), ResolvePath(), string.ParsePath(), etc.
• A general feeling that maintaining that doc was too much of a pain and a keeping-things-in-sync problem, and that this was better achieved through generating docs from the source here in ipfs/go-ipfs.

It may be that this was really a “sigh, this is just the unfortunate state of things” opinion and not an official position, but I am interested in making sure we are taking a pragmatic approach that best serves the users of these tools. Things like these empty specs are a real problem. I don’t recall if it was somewhere in a GitHub issue, on discuss.ipfs.io, or on IRC, but I found at least one person thinking there was no way to use the API in Go or use go-ipfs as a library because all the Go entries in interface-ipfs-core say “WIP.” I’m all for trying to get things cohesive and unified, but we need to paint a realistic picture for the community about what’s actually happening (not just what we aspire to) and always communicate status and timeframe wherever things are left in a halfway state.