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

rename *-ipfs-api to *-ipfs-http-client ?? #374

Open
daviddias opened this Issue Nov 14, 2018 · 28 comments

Comments

Projects
None yet
@daviddias
Copy link
Member

daviddias commented Nov 14, 2018

It is a bit of mouthful to explain that the js-ipfs-api is the client library that implements the same js-ipfs API but it is just a client.

Other project call these libraries SDK or simply, clients.

Fun history fact, we had multiple confused users opening multiple issues assuming that js-ipfs-api is the JS implementation. It only stopped when we put a giant banner image in every repo that is a client library -> https://github.com/ipfs/js-ipfs-api/#--

@Stebalien

This comment has been minimized.

Copy link
Contributor

Stebalien commented Nov 15, 2018

Go can do this when we finish the CoreAPI and re-write the client... (otherwise, we break imports).

This was referenced Nov 15, 2018

@alexander255

This comment has been minimized.

Copy link

alexander255 commented Nov 15, 2018

Naming it -client makes it sound like the given module is an IPFS client (something that talks bitswap/etc but cannot serve anything). If you want it to have an unambiguous name I'd suggest -api-client althrough it's longer.

@Stebalien

This comment has been minimized.

Copy link
Contributor

Stebalien commented Nov 15, 2018

Hm. Yeah, you have a good point.

@ianopolous

This comment has been minimized.

Copy link
Member

ianopolous commented Nov 15, 2018

Seems reasonable to me.

If we're considering -api-client I think -http-client might be more obvious.

@daviddias daviddias changed the title rename *-ipfs-api to *-ipfs-client ?? rename *-ipfs-api to *-ipfs-http-client ?? Nov 15, 2018

@daviddias

This comment has been minimized.

Copy link
Member Author

daviddias commented Nov 15, 2018

thumbsup this comment if you agree with renaming *-ipfs-api to *-ipfs-http-client

@cloutier

This comment has been minimized.

Copy link

cloutier commented Nov 16, 2018

I'm on board for my client! I might keep the old name around with a warning to make sure to not break anything.

@daviddias

This comment has been minimized.

Copy link
Member Author

daviddias commented Nov 17, 2018

image

Seems that we've reached a quorum :) Now we just need to get them renamed everywhere :)

@digitalkaoz

This comment has been minimized.

Copy link
Contributor

digitalkaoz commented Nov 25, 2018

The PHP library can also talk with a Socket...so a rename would Not be 💯% correct

@daviddias

This comment has been minimized.

Copy link
Member Author

daviddias commented Dec 3, 2018

@whyrusleeping

This comment has been minimized.

Copy link
Member

whyrusleeping commented Dec 3, 2018

why not just 'ipfs-api-client'? binding it to http specifically seems... antithetical

@vmx

This comment has been minimized.

Copy link
Member

vmx commented Dec 3, 2018

@whyrusleeping Currently it is http only, which actually surprised me when I first got started on IPFS. I'm happy that it is clear now that at the moment clients usually use the HTTP protocol.

@ianopolous

This comment has been minimized.

Copy link
Member

ianopolous commented Dec 3, 2018

I don't seem to have the permissions to rename, https://github.com/ipfs/java-ipfs-api
Can someone grant them to me?

@daviddias

This comment has been minimized.

Copy link
Member Author

daviddias commented Dec 3, 2018

@ianopolous made you an admin :)

@raulk

This comment has been minimized.

Copy link
Member

raulk commented Dec 4, 2018

Two cents from somebody in a galaxy far far away (not really, libp2p)...

ipfs-api-client is redundant to me because: how else would a client talk to a service if not via an API (whatever the interface and wire format is)? EDIT: just read @alexander255's comment above, and it makes sense too. -api-client makes it clearer that this is an SDK, not a client application.

Including the actual interface type (http) in the name is short-sighted IMO:

  1. We don't want to orchestrate another massive rename after introducing support for Unix sockets, Windows Named Pipes, gRPC, etc.
  2. In the future we might use a libp2p RPC library, which will be multitransport by default.
  3. Whether the backing service is reached via HTTP, gRPC, Unix sockets, etc. the front-facing API would remain the same. Hypothetical ipfs-api-[ipc/http/grpc]-client modules would duplicate a lot of code.

ipfs-client seems appropriate to me, using an adapter-like design to choose HTTP, IPC, gRPC backends while exposing the same frontend.

@NeoTeo

This comment has been minimized.

Copy link

NeoTeo commented Dec 4, 2018

Of the suggestions and arguments so far I like this the best, but ipfs-client does read as though it's just an application/tool. If we can assume that these are always in the form of libraries how aboutipfs-client-library or ipfs-client-lib ?

@whyrusleeping

This comment has been minimized.

Copy link
Member

whyrusleeping commented Dec 5, 2018

@raulk To me, just ipfs-client sounds like it actually contains the client implementation of ipfs. Which is misleading.

Agree strongly that putting http in the title is super short sighted. Would be great for far reaching decisions like this to be floated around a bit more before committing to them so widely

@ianopolous

This comment has been minimized.

Copy link
Member

ianopolous commented Dec 5, 2018

@whyrusleeping At least for the Java http client it will always be just that, a http client. If there is some other protocol a client can be based on, then that would be a different project. Things may be different for the go client, which already conflates http with cmd line based calls.

@whyrusleeping

This comment has been minimized.

Copy link
Member

whyrusleeping commented Dec 5, 2018

@ianopolous i'm sure that the java api client could be easily made to work over websockets, making it also work via a unix domain socket doesnt seem too farfetched either. Would you make those all into different packages?

@ianopolous

This comment has been minimized.

Copy link
Member

ianopolous commented Dec 5, 2018

@whyrusleeping I've never seen a java sdk for any service that used websockets, if I did need something like that I'd just use a normal socket. If that was a useful thing for ipfs, and there was a lot of code duplication with the http client, then personally I'd factor out the common code into a library (and ideally make it even more protocol agnostic).

Note that mixing two different protocols in the same client can create possibility for confusion and bugs: ipfs/go-ipfs#5784

lidel added a commit to ipfs-shipyard/ipfs-companion that referenced this issue Dec 10, 2018

@raulk

This comment has been minimized.

Copy link
Member

raulk commented Dec 10, 2018

@ianopolous Let's park the websockets discussion for now and assume we want client SDKs that can support multiple backend interfaces (whatever those might be).

To model this in Java, you'd normally have a core module that defines the skeleton, public API, abstractions, DTOs, etc. And then you'd have any number of modules each adding support for a different backend protocol. They all implement an adapter interface from core.

You'd normally import these into the build with <scope>runtime</scope> (Maven), and core might even use a mechanism like SPI (Service Provider Interface) to discover which adapters are available at runtime, and use the optimal one (even performing some kind of fallback or negotiation). Or you could rely on the user to specify which one to use at compile time, e.g.

ipfsClient.setBackend(HttpApiBackend.class);     // public void setBackend(Class<? extends IpfsBackend> clz);

BTW – web3j supports HTTP, IPC and WSS in the same Java module, and as long as the API is modelled nicely, the only burden this adds is pulling potentially unused dependencies.

@ianopolous

This comment has been minimized.

Copy link
Member

ianopolous commented Dec 10, 2018

@raulk

assume we want client SDKs that can support multiple backend interfaces (whatever those might be).

I definitely don't want that. Putting all protocols in the same library has several downsides. It makes the size of the library both in source and binary O(N) where N is the number of protocols. Almost all the time I only want a single protocol implementation of a sdk, and I'd rather not have a library where 90% is extraneous to me, bloating my app, but leaving me no easy way to remove it. Also if I care about security and need to audit my dependencies that is a huge blowout in complexity and expense for no reason at all.

I'm not saying such a universal client shouldn't exist. Maybe there is a use case for it, but it shouldn't be forced on people.

@raulk

This comment has been minimized.

Copy link
Member

raulk commented Dec 10, 2018

@ianopolous I think you’re assuming an uber-JAR model. What I’m talking about is the opposite: a multi-module build, where dependencies don’t leak across modules and are only pulled when the end user adds that module to their build. For an example, you can check out the Apache Camel project, which hosts over 200 adapters for different technologies. As a user, I add camel-core (very slim) + the components I want to use (camel-mqtt, camel-ftp, etc.) and let Maven/Gradle calculate the effective dependency graph for me.

@digitalkaoz

This comment has been minimized.

Copy link
Contributor

digitalkaoz commented Dec 24, 2018

im against renaming it to http-client. as i said before the php-api-client can talk to an html endpoint or to an socket. its just another driver, the rest of the code is completely the same. so im on the side that http-* is not farsighted. but im ok with renaming to LANG-ipfs-client or LANG-ipfs-api-client

@alexander255

This comment has been minimized.

Copy link

alexander255 commented Dec 24, 2018

I fully agree with @digitalkaoz: It depends, I guess, on whether given client library envisions supporting other transports or not. (The Python library for that matter likely will, since it already has pluggable transports and we can easily have optional dependencies in scripting languages.)

@daviddias daviddias added the ready label Jan 7, 2019

@Kubuxu

This comment has been minimized.

Copy link
Member

Kubuxu commented Feb 11, 2019

This was done. Closing.

@Kubuxu Kubuxu closed this Feb 11, 2019

@wafflebot wafflebot bot removed the ready label Feb 11, 2019

@daviddias daviddias reopened this Feb 12, 2019

@daviddias

This comment has been minimized.

Copy link
Member Author

daviddias commented Feb 12, 2019

@Kubuxu let's use to track the migration of all the other packages. See the issues linked.

@Kubuxu

This comment has been minimized.

Copy link
Member

Kubuxu commented Feb 12, 2019

Ok, sorry about that.

@sameer

This comment has been minimized.

Copy link

sameer commented Feb 15, 2019

Should all HTTP API client implementations be renaming themselves now to ipfs-http-client?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment