Ipfs: rename *-ipfs-api to *-ipfs-http-client ??

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

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.

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 *-ipfs-api to *-ipfs-http-client

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

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

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

Blog post by @alanshaw https://blog.ipfs.io/58-http-client-rename/ \o/

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
Can someone grant them to me?

@ianopolous made you an admin :)

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.

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 oripfs-client-lib ?

@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

@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: https://github.com/ipfs/go-ipfs/issues/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 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.

@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.

@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 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

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.