Skip to content
This repository has been archived by the owner on Oct 5, 2023. It is now read-only.

Consider the place of non-core APIs #17

Open
Stebalien opened this issue May 6, 2019 · 4 comments
Open

Consider the place of non-core APIs #17

Stebalien opened this issue May 6, 2019 · 4 comments

Comments

@Stebalien
Copy link
Member

For example, log/tail. These are useful APIs but we may not want to stabilize them. Thoughts? We do expose Request so we could, alternatively, provide some kind of "unstable" wrapper:

type UnstableAPI struct {
  *HttpApi
}

... unstable stuff

Or we could just document these interfaces as "unstable".

@Stebalien
Copy link
Member Author

cc @postables, @magik6k?

@magik6k
Copy link
Member

magik6k commented May 6, 2019

I like this. We probably should also have UnstableAPI defined in https://github.com/ipfs/interface-go-ipfs-core, to at lest keep consistency between implementations.

@magik6k
Copy link
Member

magik6k commented May 6, 2019

(related - ipfs/go-ipfs-api#179 (comment))

@bonedaddy
Copy link
Contributor

I like the idea of using an UnstableAPI wrapper as well, and second what magik6k said about defining it in interface-go-ipfs-core.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants