Ipfs: 将 *-ipfs-api 重命名为 *-ipfs-http-client ??

当我们完成 CoreAPI 并重新编写客户端时，Go 可以做到这一点......（否则，我们会中断导入）。

将其命名为-client听起来就像给定的模块是一个IPFS客户端（可以说 bitswap/etc 但不能提供任何服务的东西）。 如果您希望它有一个明确的名称，我建议-api-client althrough 它更长。

嗯。 是的，你有一个很好的观点。

对我来说似乎很合理。

如果我们正在考虑 -api-client 我认为 -http-client 可能更明显。

如果您同意将*-ipfs-api重命名为*-ipfs-http-client ，请点赞此评论

我在船上为我的客户！ 我可能会保留旧名称并发出警告，以确保不会破坏任何东西。

似乎我们已经达到了法定人数 :) 现在我们只需要让它们在任何地方重命名 :)

PHP 库也可以与 Socket 通信...所以重命名不会 💯% 正确

@alanshaw的博客文章https://blog.ipfs.io/58-http-client-rename/ \o/

为什么不只是'ipfs-api-client'？ 将其绑定到 http 似乎...对立

@whyrusleeping目前它只是 http，当我第一次开始使用 IPFS 时，这让我很惊讶。 我很高兴现在很清楚，目前客户端通常使用 HTTP 协议。

我似乎没有重命名的权限， https://github.com/ipfs/java-ipfs-api
有人可以将它们授予我吗？

@ianopolous让你成为管理员 :)

来自遥远星系中某人的两美分（不是真的，libp2p）......

ipfs-api-client对我来说是多余的，因为：如果不通过 API（无论接口和线路格式是什么），客户端如何与服务通信？ 编辑：只需阅读上面@alexander255的评论，这也很有意义。 -api-client更清楚地表明这是一个 SDK，而不是客户端应用程序。

在名称中包含实际的接口类型（http）是短视的IMO：

1. 在引入对 Unix 套接字、Windows 命名管道、gRPC 等的支持之后，我们不想再安排一次大规模的重命名。
2. 将来我们可能会使用 libp2p RPC 库，默认情况下它是多传输的。
3. 无论是通过 HTTP、gRPC、Unix 套接字等访问后端服务，前端 API 都将保持不变。 假设的ipfs-api-[ipc/http/grpc]-client模块会复制大量代码。

ipfs-client对我来说似乎很合适，使用类似适配器的设计来选择 HTTP、IPC、gRPC 后端，同时暴露相同的前端。

在迄今为止的建议和论点中，我最喜欢这个，但ipfs-client读起来好像它只是一个应用程序/工具。 如果我们可以假设这些总是以库的形式存在，那么ipfs-client-library或ipfs-client-lib怎么样？

@raulk对我来说，只是ipfs-client听起来它实际上包含 ipfs 的客户端实现。 这是误导。

强烈同意将http放在标题中是超级短视的。 对于像这样影响深远的决定，在如此广泛地做出承诺之前，再多考虑一下会很好

@whyrusleeping至少对于 Java http 客户端来说，它永远只是一个 http 客户端。 如果客户端可以基于其他协议，那么这将是一个不同的项目。 go 客户端的情况可能有所不同，它已经将 http 与基于 cmd 行的调用混为一谈。

@ianopolous我确信java api客户端可以很容易地在websockets上工作，使它也可以通过unix域套接字工作似乎也不太牵强。 你会把这些都做成不同的包吗？

@whyrusleeping我从未见过任何使用websockets的服务的java sdk，如果我确实需要类似的东西，我只会使用普通的套接字。 如果这对 ipfs 有用，并且与 http 客户端有很多代码重复，那么我个人会将通用代码分解到库中（理想情况下，使其与协议更加无关）。

请注意，在同一个客户端中混合两种不同的协议可能会造成混淆和错误： https ://github.com/ipfs/go-ipfs/issues/5784

@ianopolous让我们暂时搁置 websockets 讨论，并假设我们想要可以支持多个后端接口（无论可能是什么）的客户端 SDK。

要在 Java 中对此进行建模，您通常需要一个core模块来定义框架、公共 API、抽象、DTO 等。然后您将拥有任意数量的模块，每个模块都添加对不同后端的支持协议。 它们都从core实现了一个适配器接口。

您通常会使用<scope>runtime</scope> (Maven) 将这些导入到构建中，并且core甚至可能使用诸如 SPI（服务提供者接口）之类的机制来发现哪些适配器在运行时可用，并使用最佳的（甚至执行某种回退或协商）。 或者您可以依靠用户指定在编译时使用哪一个，例如

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

顺便说一句——web3j在同一个 Java 模块中支持 HTTP、IPC 和 WSS，只要 API 建模良好，这增加的唯一负担就是拉动可能未使用的依赖项。

@raulk

假设我们想要可以支持多个后端接口（无论是什么）的客户端 SDK。

我绝对不想那样。 将所有协议放在同一个库中有几个缺点。 它使库的大小在源代码和二进制 O(N) 中都有，其中 N 是协议的数量。 几乎一直以来，我只想要一个 sdk 的单一协议实现，而且我宁愿没有一个库，其中 90% 对我来说是无关紧要的，这会使我的应用程序膨胀，但让我无法轻松删除它。 此外，如果我关心安全性并需要审核我的依赖项，那将毫无理由地增加复杂性和费用。

我并不是说这样的通用客户端不应该存在。 也许它有一个用例，但不应该强加于人。

@ianopolous我认为您假设的是 uber-JAR 模型。 我所说的是相反的：多模块构建，其中依赖项不会跨模块泄漏，并且仅在最终用户将该模块添加到他们的构建时才被拉取。 例如，您可以查看Apache Camel项目，该项目托管了 200 多个适用于不同技术的适配器。 作为用户，我添加了 camel-core（非常苗条）+ 我想使用的组件（camel-mqtt、camel-ftp 等）并让 Maven/Gradle 为我计算有效的依赖关系图。

我反对将其重命名为http-client 。 正如我之前所说， php-api-client可以与 html 端点或套接字对话。 它只是另一个驱动程序，其余代码完全相同。 所以我认为http-*不是有远见的。 但我可以重命名为LANG-ipfs-client或LANG-ipfs-api-client

我完全同意@digitalkaoz ：我想这取决于给定的客户端库是否设想支持其他传输。 （与此相关的 Python 库可能会，因为它已经具有可插入的传输，并且我们可以轻松地在脚本语言中拥有可选的依赖项。）

这样做了。 关闭。

@Kubuxu让我们用来跟踪所有其他包的迁移。 查看链接的问题。

好的，对此感到抱歉。

所有 HTTP API 客户端实现现在都应该重命名为 ipfs-http-client 吗？

似乎有一些实现没有效仿，但保持开放也无济于事。 我们建议尽可能更新名称。