-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
Go can do this when we finish the CoreAPI and re-write the client... (otherwise, we break imports). |
Naming it |
Hm. Yeah, you have a good point. |
Seems reasonable to me. If we're considering -api-client I think -http-client might be more obvious. |
thumbsup this comment if you agree with renaming |
I'm on board for my client! I might keep the old name around with a warning to make sure to not break anything. |
why not just 'ipfs-api-client'? binding it to http specifically seems... antithetical |
@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. |
I don't seem to have the permissions to rename, https://github.com/ipfs/java-ipfs-api |
@ianopolous made you an admin :) |
Two cents from somebody in a galaxy far far away (not really, libp2p)...
Including the actual interface type (http) in the name is short-sighted IMO:
|
Of the suggestions and arguments so far I like this the best, but |
@raulk To me, just Agree strongly that putting |
@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. |
@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? |
@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/kubo#5784 |
@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 You'd normally import these into the build with
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. |
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. |
@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. |
im against renaming it to |
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.) |
This was done. Closing. |
@Kubuxu let's use to track the migration of all the other packages. See the issues linked. |
Ok, sorry about that. |
Should all HTTP API client implementations be renaming themselves now to ipfs-http-client? |
It seems a few implementations did not follow suit, but keeping this open does not help too much either. We recommend to update the name though, when possible. |
It is a bit of mouthful to explain that the
js-ipfs-api
is the client library that implements the samejs-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/#--The text was updated successfully, but these errors were encountered: