Ipfs: *-ipfs-apiの名前を*-ipfs-http-clientに変更しますか？

CoreAPIを終了し、クライアントを書き直したときに、Goはこれを実行できます...（そうでない場合は、インポートを中断します）。

-clientという名前を付けると、指定されたモジュールがIPFSクライアント（bitswap / etcと通信するが、何も提供できないもの）であるように聞こえます。 明確な名前を付けたい場合は、 -api-clientの方が長いことをお勧めします。

うーん。 ええ、あなたには良い点があります。

私には合理的なようです。

-api-clientを検討している場合は、-http-clientの方がわかりやすいと思います。

*-ipfs-apiの名前を$ *-ipfs-http-clientに変更することに同意する場合は、このコメントをthumbsupします。

私は私のクライアントのために乗っています！ 何も壊さないように、古い名前を警告とともに保持する場合があります。

クォーラムに達したようです:)今、どこでも名前を変更する必要があります:)

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はあなたを管理者にしました:)

遠く離れた銀河の誰かから2セント（実際には、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少なくともJavahttpクライアントの場合、それは常にそれ、つまりhttpクライアントになります。 クライアントが基づくことができる他のプロトコルがある場合、それは別のプロジェクトになります。 すでにhttpをcmd行ベースの呼び出しで圧縮しているgoクライアントでは状況が異なる場合があります。

@ianopolous java apiクライアントをWebSocketで簡単に動作させることができると確信しています。また、unixドメインソケットを介して動作させることも、あまり先取りされていないようです。 それらをすべて別のパッケージにしますか？

@whyrusleeping WebSocketを使用するサービスのJavaSDKを見たことがありません。そのようなものが必要な場合は、通常のソケットを使用します。 それがipfsにとって有用なことであり、httpクライアントで多くのコードの重複があった場合、個人的には共通のコードをライブラリに除外します（理想的には、プロトコルに依存しないようにします）。

同じクライアントで2つの異なるプロトコルを混在させると、混乱やバグが発生する可能性があることに注意してください： https ://github.com/ipfs/go-ipfs/issues/5784

@ianopolousとりあえず、WebSocketの議論を止めて、複数のバックエンドインターフェイス（それらが何であれ）をサポートできるクライアントSDKが必要だと仮定しましょう。

これをJavaでモデル化するには、通常、スケルトン、パブリックAPI、抽象化、DTOなどを定義するcoreモジュールがあります。次に、それぞれが異なるバックエンドのサポートを追加する任意の数のモジュールがあります。プロトコル。 それらはすべて、 coreからのアダプタインターフェイスを実装します。

通常、これらは<scope>runtime</scope> （Maven）を使用してビルドにインポートします。また、 coreは、SPI（Service Provider Interface）などのメカニズムを使用して、実行時に使用可能なアダプターを検出し、最適なもの（ある種のフォールバックまたはネゴシエーションを実行する場合でも）。 または、コンパイル時に使用するユーザーをユーザーに任せることもできます。

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モデルを想定していると思います。 私が話しているのは反対です。マルチモジュールビルドでは、依存関係がモジュール間でリークすることはなく、エンドユーザーがそのモジュールをビルドに追加したときにのみプルされます。 たとえば、さまざまなテクノロジー用の200を超えるアダプターをホストするApacheCamelプロジェクトを確認できます。 ユーザーとして、camel-core（非常にスリム）+使用したいコンポーネント（camel-mqtt、camel-ftpなど）を追加し、Maven/Gradleに有効な依存関係グラフを計算させます。

名前をhttp-clientに変更しないでください。 前に言ったように、 php-api-clientはhtmlエンドポイントまたはソケットと通信できます。 そのちょうど別のドライバー、コードの残りの部分は完全に同じです。 http-*は遠視ではないので、私は側にいます。 ただし、名前をLANG-ipfs-clientまたはLANG-ipfs-api-clientに変更しても問題ありません

私は@digitalkaozに完全に同意します：与えられたクライアントライブラリが他のトランスポートをサポートすることを想定しているかどうかに依存すると思います。 （Pythonライブラリには、すでにプラグイン可能なトランスポートがあり、スクリプト言語でオプションの依存関係を簡単に設定できるため、Pythonライブラリはおそらくそうなるでしょう。）

これが行われました。 閉鎖。

@Kubuxuを使用して、他のすべてのパッケージの移行を追跡しましょう。 リンクされている問題を参照してください。

わかりました、それについて申し訳ありません。

すべてのHTTPAPIクライアント実装は、今すぐipfs-http-clientに名前を変更する必要がありますか？

いくつかの実装がそれに従わなかったようですが、これを開いたままにしておくこともあまり役に立ちません。 ただし、可能であれば名前を更新することをお勧めします。