Ipfs: *-ipfs-api in *-ipfs-http-client umbenennen ??

Go kann dies tun, wenn wir die CoreAPI fertigstellen und den Client neu schreiben ... (andernfalls brechen wir Importe ab).

Die Benennung -client lässt es so klingen, als wäre das angegebene Modul ein IPFS -Client (etwas, das Bitswap/etc spricht, aber nichts bedienen kann). Wenn Sie möchten, dass es einen eindeutigen Namen hat, würde ich -api-client vorschlagen, obwohl es länger ist.

Hm. Ja, du hast einen guten Punkt.

Scheint mir vernünftig.

Wenn wir -api-client in Betracht ziehen, denke ich, dass -http-client offensichtlicher ist.

Daumen hoch für diesen Kommentar, wenn Sie damit einverstanden sind, *-ipfs-api in *-ipfs-http-client umzubenennen

Ich bin für meinen Kunden an Bord! Ich könnte den alten Namen mit einer Warnung beibehalten, um sicherzustellen, dass nichts kaputt geht.

Scheint, dass wir ein Quorum erreicht haben :) Jetzt müssen wir sie nur noch überall umbenennen :)

Die PHP-Bibliothek kann auch mit einem Socket sprechen ... also wäre eine Umbenennung nicht 💯% korrekt

Blogbeitrag von @alanshaw https://blog.ipfs.io/58-http-client-rename/ \o/

warum nicht einfach 'ipfs-api-client'? Die Bindung an http scheint speziell ... antithetisch zu sein

@whyrusleeping Derzeit ist es nur http, was mich tatsächlich überrascht hat, als ich zum ersten Mal mit IPFS angefangen habe. Ich bin froh, dass jetzt klar ist, dass Clients im Moment normalerweise das HTTP-Protokoll verwenden.

Ich scheine nicht die Berechtigung zum Umbenennen zu haben, https://github.com/ipfs/java-ipfs-api
Kann sie mir jemand gewähren?

@ianopolous hat dich zum Admin gemacht :)

Zwei Cent von jemandem in einer weit entfernten Galaxie (nicht wirklich, libp2p) ...

ipfs-api-client ist für mich überflüssig, weil: Wie sonst würde ein Client mit einem Dienst kommunizieren, wenn nicht über eine API (unabhängig von der Schnittstelle und dem Drahtformat)? BEARBEITEN: Lesen Sie einfach den Kommentar von @ alexander255 oben, und es macht auch Sinn. -api-client macht deutlich, dass es sich um ein SDK und nicht um eine Client-Anwendung handelt.

Die Aufnahme des tatsächlichen Schnittstellentyps (http) in den Namen ist meiner Meinung nach kurzsichtig:

1. Wir wollen keine weitere massive Umbenennung orchestrieren, nachdem wir die Unterstützung für Unix-Sockets, Windows Named Pipes, gRPC usw. eingeführt haben.
2. In Zukunft könnten wir eine libp2p-RPC-Bibliothek verwenden, die standardmäßig Multitransport sein wird.
3. Unabhängig davon, ob der unterstützende Dienst über HTTP, gRPC, Unix-Sockets usw. erreicht wird, bleibt die nach vorne gerichtete API gleich. Hypothetische ipfs-api-[ipc/http/grpc]-client -Module würden eine Menge Code duplizieren.

ipfs-client erscheint mir angemessen, da ich ein adapterähnliches Design verwende, um HTTP-, IPC- und gRPC-Backends auszuwählen, während dasselbe Frontend verfügbar gemacht wird.

Von den bisherigen Vorschlägen und Argumenten gefällt mir das am besten, aber ipfs-client liest sich so, als wäre es nur eine Anwendung/ein Tool. Wenn wir davon ausgehen können, dass diese immer in Form von Bibliotheken vorliegen, wie wäre es dann mit ipfs-client-library oder ipfs-client-lib ?

@raulk Für mich klingt nur ipfs-client so, als ob es tatsächlich die Client-Implementierung von ipfs enthält. Was irreführend ist.

Stimmen Sie voll und ganz zu, dass das Einfügen http in den Titel sehr kurzsichtig ist. Es wäre großartig, wenn weitreichende Entscheidungen wie diese ein bisschen mehr herumgewirbelt würden, bevor man sich so weit darauf einlässt

@whyrusleeping Zumindest für den Java-http-Client wird es immer genau das sein, ein http-Client. Wenn es ein anderes Protokoll gibt, auf dem ein Client basieren kann, dann wäre das ein anderes Projekt. Für den go-Client kann es anders sein, der bereits http mit auf cmd-Zeilen basierenden Aufrufen zusammenführt.

@ianopolous Ich bin mir sicher, dass der Java-API-Client leicht über Websockets zum Laufen gebracht werden könnte, sodass es auch nicht zu weit hergeholt erscheint, dass er auch über einen Unix-Domain-Socket funktioniert. Würden Sie das alles in verschiedene Pakete packen?

@whyrusleeping Ich habe noch nie ein Java-SDK für einen Dienst gesehen, der Websockets verwendet. Wenn ich so etwas bräuchte, würde ich einfach einen normalen Socket verwenden. Wenn das eine nützliche Sache für ipfs wäre und es viel Codeduplizierung mit dem http-Client gab, dann würde ich persönlich den gemeinsamen Code in eine Bibliothek auslagern (und ihn idealerweise noch protokollagnostischer machen).

Beachten Sie, dass das Mischen von zwei verschiedenen Protokollen im selben Client zu Verwirrung und Fehlern führen kann: https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous Lassen Sie uns die Websockets-Diskussion vorerst parken und davon ausgehen, dass wir Client-SDKs wollen, die mehrere Backend-Schnittstellen unterstützen können (was auch immer das sein mag).

Um dies in Java zu modellieren, hätten Sie normalerweise ein core -Modul, das das Skelett, die öffentliche API, Abstraktionen, DTOs usw. definiert. Und dann hätten Sie eine beliebige Anzahl von Modulen, die jeweils Unterstützung für ein anderes Backend hinzufügen Protokoll. Sie alle implementieren eine Adapterschnittstelle von core .

Normalerweise würden Sie diese mit <scope>runtime</scope> (Maven) in den Build importieren, und core könnte sogar einen Mechanismus wie SPI (Service Provider Interface) verwenden, um zu ermitteln, welche Adapter zur Laufzeit verfügbar sind, und diese zu verwenden die optimale (sogar durch eine Art Fallback oder Verhandlung). Oder Sie können sich darauf verlassen, dass der Benutzer zur Kompilierungszeit angibt, welche verwendet werden soll, z

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

Übrigens – web3j unterstützt HTTP, IPC und WSS im selben Java-Modul, und solange die API gut modelliert ist, besteht die einzige zusätzliche Belastung darin, potenziell ungenutzte Abhängigkeiten zu ziehen.

@Raulk

Angenommen, wir wollen Client-SDKs, die mehrere Backend-Schnittstellen unterstützen können (was auch immer das sein mag).

Das will ich definitiv nicht. Das Platzieren aller Protokolle in derselben Bibliothek hat mehrere Nachteile. Es macht die Größe der Bibliothek sowohl im Quell- als auch im Binärformat O(N), wobei N die Anzahl der Protokolle ist. Fast immer möchte ich nur eine einzelne Protokollimplementierung eines SDK, und ich möchte lieber keine Bibliothek haben, in der 90 % für mich fremd sind, was meine App aufbläht, mir aber keine einfache Möglichkeit lässt, sie zu entfernen. Auch wenn ich mich um Sicherheit kümmere und meine Abhängigkeiten prüfen muss, ist das völlig grundlos ein enormer Aufwand an Komplexität und Kosten.

Ich sage nicht, dass ein solcher universeller Client nicht existieren sollte. Vielleicht gibt es einen Anwendungsfall dafür, aber es sollte den Leuten nicht aufgezwungen werden.

@ianopolous Ich denke, Sie gehen von einem Über-JAR-Modell aus. Wovon ich spreche, ist das Gegenteil: ein Build mit mehreren Modulen , bei dem Abhängigkeiten nicht zwischen Modulen durchsickern und nur abgerufen werden, wenn der Endbenutzer dieses Modul zu seinem Build hinzufügt. Als Beispiel können Sie sich das Apache Camel -Projekt ansehen, das über 200 Adapter für verschiedene Technologien hostet. Als Benutzer füge ich camel-core (sehr schlank) + die Komponenten hinzu, die ich verwenden möchte (camel-mqtt, camel-ftp usw.) und lasse Maven/Gradle den effektiven Abhängigkeitsgraphen für mich berechnen.

Ich bin dagegen, es in http-client . Wie ich bereits sagte, kann der PHP-API-Client mit einem HTML-Endpunkt oder einem Socket kommunizieren. Es ist nur ein weiterer Treiber , der Rest des Codes ist völlig gleich. Also ich bin auf der Seite, dass http-* nicht weitsichtig ist. aber im ok mit der Umbenennung in LANG-ipfs-client oder LANG-ipfs-api-client

Ich stimme @digitalkaoz voll und ganz zu: Es hängt, denke ich, davon ab, ob eine bestimmte Client-Bibliothek andere Transporte unterstützen möchte oder nicht. (Die Python-Bibliothek wird dies wahrscheinlich tun, da sie bereits austauschbare Transporte hat und wir problemlos optionale Abhängigkeiten in Skriptsprachen haben können.)

Dies wurde gemacht. Schließen.

@Kubuxu verwenden wir, um die Migration aller anderen Pakete zu verfolgen. Siehe die verlinkten Probleme.

Okay, tut mir leid.

Sollten sich alle HTTP-API-Client-Implementierungen jetzt in ipfs-http-client umbenennen?

Es scheint, dass einige Implementierungen nicht nachgezogen haben, aber dies offen zu halten, hilft auch nicht allzu viel. Wir empfehlen jedoch, den Namen nach Möglichkeit zu aktualisieren.