Ipfs: renommer *-ipfs-api en *-ipfs-http-client ??

Go peut le faire lorsque nous terminons le CoreAPI et réécrivons le client... (sinon, nous cassons les importations).

Le nommer -client donne l'impression que le module donné est un client IPFS (quelque chose qui parle bitswap/etc mais ne peut rien servir). Si vous voulez qu'il ait un nom sans ambiguïté, je suggérerais -api-client bien qu'il soit plus long.

Hum. Oui, vous avez un bon point.

Cela me semble raisonnable.

Si nous envisageons -api-client, je pense que -http-client pourrait être plus évident.

pouce vers le haut de ce commentaire si vous êtes d'accord pour renommer *-ipfs-api en *-ipfs-http-client

Je suis à bord pour mon client ! Je pourrais garder l'ancien nom avec un avertissement pour m'assurer de ne rien casser.

Il semble que nous ayons atteint un quorum :) Il ne nous reste plus qu'à les renommer partout :)

La bibliothèque PHP peut également parler avec un Socket ... donc un changement de nom ne serait pas 💯% correct

Article de blog par @alanshaw https://blog.ipfs.io/58-http-client-rename/ \o/

pourquoi ne pas simplement "ipfs-api-client" ? le lier à http semble spécifiquement ... antithétique

@whyrusleeping Actuellement, il s'agit uniquement de http, ce qui m'a surpris lorsque j'ai commencé à utiliser IPFS. Je suis heureux qu'il soit clair maintenant qu'à l'heure actuelle, les clients utilisent généralement le protocole HTTP.

Je ne semble pas avoir les autorisations pour renommer, https://github.com/ipfs/java-ipfs-api
Quelqu'un peut-il me les accorder ?

@ianopolous t'a nommé admin :)

Deux centimes de quelqu'un dans une galaxie très lointaine (pas vraiment, libp2p)...

ipfs-api-client est redondant pour moi car : sinon, comment un client pourrait-il parler à un service si ce n'est via une API (quels que soient l'interface et le format de connexion) ? EDIT : il suffit de lire le commentaire de @ alexander255 ci-dessus, et cela a également du sens. -api-client indique plus clairement qu'il s'agit d'un SDK, et non d'une application cliente.

Inclure le type d'interface réel (http) dans le nom est à courte vue IMO :

1. Nous ne voulons pas orchestrer un autre changement de nom massif après avoir introduit la prise en charge des sockets Unix, des canaux nommés Windows, de gRPC, etc.
2. À l'avenir, nous pourrions utiliser une bibliothèque RPC libp2p, qui sera multitransport par défaut.
3. Que le service de support soit atteint via HTTP, gRPC, sockets Unix, etc., l'API frontale resterait la même. Des modules hypothétiques ipfs-api-[ipc/http/grpc]-client dupliqueraient beaucoup de code.

ipfs-client me semble approprié, en utilisant une conception de type adaptateur pour choisir les backends HTTP, IPC, gRPC tout en exposant le même frontend.

Parmi les suggestions et les arguments jusqu'à présent, je préfère celui-ci, mais ipfs-client se lit comme s'il s'agissait simplement d'une application/d'un outil. Si nous pouvons supposer que ceux-ci sont toujours sous la forme de bibliothèques, que diriez-vous de ipfs-client-library ou ipfs-client-lib ?

@raulk Pour moi, juste ipfs-client semble contenir l'implémentation cliente d'ipfs. Ce qui est trompeur.

Convenez fortement que mettre http dans le titre est une vision à très courte vue. Ce serait formidable que des décisions de grande envergure comme celle-ci soient débattues un peu plus avant de s'y engager si largement

@whyrusleeping Au moins pour le client http Java, ce sera toujours cela, un client http. S'il existe un autre protocole sur lequel un client peut être basé, il s'agira alors d'un projet différent. Les choses peuvent être différentes pour le client go, qui confond déjà http avec les appels basés sur la ligne cmd.

@ianopolous Je suis sûr que le client java api pourrait être facilement conçu pour fonctionner sur des websockets, le faisant également fonctionner via un socket de domaine unix ne semble pas trop tiré par les cheveux non plus. Feriez-vous tout cela dans des packages différents ?

@whyrusleeping Je n'ai jamais vu de sdk java pour un service utilisant des websockets, si j'avais besoin de quelque chose comme ça, j'utiliserais simplement un socket normal. Si c'était une chose utile pour ipfs, et qu'il y avait beaucoup de duplication de code avec le client http, alors personnellement, je factoriserais le code commun dans une bibliothèque (et idéalement le rendrais encore plus indépendant du protocole).

Notez que le mélange de deux protocoles différents dans le même client peut créer des risques de confusion et de bogues : https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous Gardons la discussion sur les websockets pour l'instant et supposons que nous voulons des SDK clients capables de prendre en charge plusieurs interfaces backend (quelles qu'elles soient).

Pour modéliser cela en Java, vous auriez normalement un module core qui définit le squelette, l'API publique, les abstractions, les DTO, etc. Et puis vous auriez n'importe quel nombre de modules chacun ajoutant le support pour un backend différent protocole. Ils implémentent tous une interface d'adaptateur à partir de core .

Vous devriez normalement les importer dans la construction avec <scope>runtime</scope> (Maven), et core pourrait même utiliser un mécanisme comme SPI (Service Provider Interface) pour découvrir quels adaptateurs sont disponibles au moment de l'exécution, et utiliser l'optimal (même en effectuant une sorte de repli ou de négociation). Ou vous pouvez compter sur l'utilisateur pour spécifier lequel utiliser au moment de la compilation, par exemple

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

BTW - web3j prend en charge HTTP, IPC et WSS dans le même module Java, et tant que l'API est bien modélisée, le seul fardeau que cela ajoute est de tirer des dépendances potentiellement inutilisées.

@raulk

supposons que nous voulions des SDK clients capables de prendre en charge plusieurs interfaces backend (quelles qu'elles soient).

Je ne veux absolument pas ça. Mettre tous les protocoles dans la même bibliothèque a plusieurs inconvénients. Il rend la taille de la bibliothèque à la fois source et binaire O(N) où N est le nombre de protocoles. Presque tout le temps, je ne veux qu'une seule implémentation de protocole d'un sdk, et je préfère ne pas avoir une bibliothèque où 90% m'est étranger, gonflant mon application, mais ne me laissant aucun moyen facile de la supprimer. De plus, si je me soucie de la sécurité et que j'ai besoin d'auditer mes dépendances, c'est une énorme explosion de complexité et de dépenses sans aucune raison.

Je ne dis pas qu'un tel client universel ne devrait pas exister. Il y a peut-être un cas d'utilisation pour cela, mais cela ne devrait pas être imposé aux gens.

@ianopolous Je pense que vous supposez un modèle uber-JAR. Ce dont je parle est le contraire : une construction multi-module , où les dépendances ne fuient pas entre les modules et ne sont extraites que lorsque l'utilisateur final ajoute ce module à sa construction. Par exemple, vous pouvez consulter le projet Apache Camel , qui héberge plus de 200 adaptateurs pour différentes technologies. En tant qu'utilisateur, j'ajoute camel-core (très mince) + les composants que je veux utiliser (camel-mqtt, camel-ftp, etc.) et laisse Maven/Gradle calculer le graphe de dépendance effectif pour moi.

je suis contre le renommer en http-client . comme je l'ai déjà dit, le php-api-client peut parler à un point de terminaison html ou à un socket. c'est juste un autre pilote , le reste du code est complètement le même. donc je suis du côté que http-* n'est pas presbyte. mais je suis d'accord pour renommer en LANG-ipfs-client ou LANG-ipfs-api-client

Je suis entièrement d'accord avec @digitalkaoz : cela dépend, je suppose, si une bibliothèque cliente donnée envisage de prendre en charge d'autres transports ou non. (La bibliothèque Python d'ailleurs le sera probablement, car elle a déjà des transports enfichables et nous pouvons facilement avoir des dépendances facultatives dans les langages de script.)

Cela a été fait. Fermeture.

@Kubuxu utilisons pour suivre la migration de tous les autres packages. Voir les problèmes liés.

Ok, désolé pour ça.

Toutes les implémentations de client HTTP API devraient-elles se renommer maintenant en ipfs-http-client ?

Il semble que quelques implémentations n'aient pas emboîté le pas, mais garder cela ouvert n'aide pas trop non plus. Nous vous recommandons cependant de mettre à jour le nom, si possible.