Ipfs: cambiar el nombre de *-ipfs-api a *-ipfs-http-client ??

Go puede hacer esto cuando terminemos CoreAPI y reescribamos el cliente... (de lo contrario, interrumpiremos las importaciones).

Nombrarlo -client hace que parezca que el módulo dado es un cliente IPFS (algo que habla bitswap/etc pero no sirve para nada). Si desea que tenga un nombre inequívoco, le sugiero -api-client , aunque es más largo.

Hm. Sí, tienes un buen punto.

Me parece razonable.

Si estamos considerando -api-client, creo que -http-client podría ser más obvio.

Me gusta este comentario si está de acuerdo con cambiar el nombre *-ipfs-api a *-ipfs-http-client

¡Estoy a bordo para mi cliente ! Podría mantener el nombre anterior con una advertencia para asegurarme de no romper nada.

Parece que hemos alcanzado un quórum :) Ahora solo tenemos que cambiarles el nombre en todas partes :)

La biblioteca PHP también puede comunicarse con un Socket... por lo que un cambio de nombre no sería 💯% correcto

Publicación de blog de @alanshaw https://blog.ipfs.io/58-http-client-rename/ \o/

¿por qué no simplemente 'ipfs-api-client'? vincularlo a http específicamente parece... antitético

@whyrusleeping Actualmente es solo http, lo que en realidad me sorprendió cuando comencé con IPFS. Estoy feliz de que ahora quede claro que, en este momento, los clientes suelen usar el protocolo HTTP.

Parece que no tengo los permisos para cambiar el nombre, https://github.com/ipfs/java-ipfs-api
¿Alguien me los puede conceder?

@ianopolous te hizo administrador :)

Dos centavos de alguien en una galaxia muy, muy lejana (no realmente, libp2p)...

ipfs-api-client es redundante para mí porque: ¿de qué otra manera un cliente hablaría con un servicio si no fuera a través de una API (cualquiera que sea la interfaz y el formato de conexión)? EDITAR: solo lea el comentario anterior de @ alexander255 , y también tiene sentido. -api-client aclara que se trata de un SDK, no de una aplicación cliente.

Incluir el tipo de interfaz real (http) en el nombre es una OMI miope:

1. No queremos orquestar otro cambio de nombre masivo después de introducir soporte para sockets de Unix, canalizaciones con nombre de Windows, gRPC, etc.
2. En el futuro podríamos usar una biblioteca RPC libp2p, que será multitransporte por defecto.
3. Ya sea que se acceda al servicio de respaldo a través de HTTP, gRPC, sockets Unix, etc., la API frontal seguirá siendo la misma. Los módulos hipotéticos ipfs-api-[ipc/http/grpc]-client duplicarían una gran cantidad de código.

ipfs-client me parece apropiado, usar un diseño similar a un adaptador para elegir backends HTTP, IPC, gRPC mientras se expone la misma interfaz.

De las sugerencias y argumentos hasta ahora, este es el que más me gusta, pero ipfs-client se lee como si fuera solo una aplicación/herramienta. Si podemos suponer que estos siempre están en forma de bibliotecas, ¿qué tal ipfs-client-library o ipfs-client-lib ?

@raulk Para mí, solo ipfs-client parece que en realidad contiene la implementación del cliente de ipfs. Lo cual es engañoso.

Estoy totalmente de acuerdo en que poner http en el título es muy miope. Sería genial que decisiones tan trascendentales como esta flotaran un poco más antes de comprometerse tan ampliamente con ellas.

@whyrusleeping Al menos para el cliente http de Java, siempre será solo eso, un cliente http. Si hay algún otro protocolo en el que se pueda basar un cliente, entonces ese sería un proyecto diferente. Las cosas pueden ser diferentes para el cliente go, que ya combina http con llamadas basadas en línea cmd.

@ianopolous , estoy seguro de que el cliente java api podría funcionar fácilmente a través de websockets, hacer que también funcione a través de un socket de dominio unix tampoco parece demasiado descabellado. ¿Harías esos todos en paquetes diferentes?

@whyrusleeping Nunca he visto un SDK de Java para ningún servicio que use websockets, si necesitara algo así, simplemente usaría un socket normal. Si eso fuera algo útil para ipfs, y hubiera mucha duplicación de código con el cliente http, entonces personalmente factorizaría el código común en una biblioteca (e idealmente lo haría aún más independiente del protocolo).

Tenga en cuenta que mezclar dos protocolos diferentes en el mismo cliente puede generar confusión y errores: https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous Dejemos la discusión sobre websockets por ahora y supongamos que queremos SDK de cliente que puedan admitir múltiples interfaces de back-end (cualesquiera que sean).

Para modelar esto en Java, normalmente tendría un módulo core que define el esqueleto, la API pública, las abstracciones, los DTO, etc. Y luego tendría cualquier cantidad de módulos, cada uno agregando soporte para un backend diferente protocolo. Todos implementan una interfaz de adaptador desde core .

Normalmente los importaría a la compilación con <scope>runtime</scope> (Maven), y core podría incluso usar un mecanismo como SPI (Interfaz de proveedor de servicios) para descubrir qué adaptadores están disponibles en tiempo de ejecución y usar la óptima (incluso realizando algún tipo de fallback o negociación). O puede confiar en que el usuario especifique cuál usar en el momento de la compilación, por ejemplo

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

Por cierto, web3j admite HTTP, IPC y WSS en el mismo módulo de Java, y siempre que la API esté bien modelada, la única carga que esto agrega es extraer dependencias potencialmente no utilizadas.

@raulk

supongamos que queremos SDK de cliente que puedan admitir múltiples interfaces de back-end (cualesquiera que sean).

Definitivamente no quiero eso. Poner todos los protocolos en la misma biblioteca tiene varias desventajas. Hace que el tamaño de la biblioteca sea tanto en fuente como en binario O(N), donde N es el número de protocolos. Casi todo el tiempo solo quiero una implementación de protocolo único de un sdk, y prefiero no tener una biblioteca donde el 90% sea extraño para mí, inflando mi aplicación, pero sin dejarme una manera fácil de eliminarla. Además, si me preocupo por la seguridad y necesito auditar mis dependencias, eso es una gran explosión en complejidad y gastos sin ningún motivo.

No digo que no deba existir un cliente tan universal. Tal vez haya un caso de uso para ello, pero no debería imponerse a las personas.

@ianopolous Creo que estás asumiendo un modelo uber-JAR. De lo que estoy hablando es de lo contrario: una compilación de varios módulos , donde las dependencias no se filtran entre los módulos y solo se extraen cuando el usuario final agrega ese módulo a su compilación. Por ejemplo, puede consultar el proyecto Apache Camel , que alberga más de 200 adaptadores para diferentes tecnologías. Como usuario, agrego camel-core (muy delgado) + los componentes que quiero usar (camel-mqtt, camel-ftp, etc.) y dejo que Maven/Gradle calcule el gráfico de dependencia efectivo por mí.

estoy en contra de cambiarle el nombre a http-client . como dije antes, el cliente php-api puede hablar con un punto final html o con un socket. es solo otro controlador , el resto del código es completamente el mismo. así que estoy del lado de que http-* no es hipermétrope. pero estoy de acuerdo con cambiar el nombre a LANG-ipfs-client o LANG-ipfs-api-client

Estoy completamente de acuerdo con @digitalkaoz : Depende, supongo, de si la biblioteca cliente dada prevé admitir otros transportes o no. (La biblioteca de Python probablemente lo hará, ya que ya tiene transportes conectables y podemos tener fácilmente dependencias opcionales en lenguajes de secuencias de comandos).

Esto se hizo. Clausura.

@Kubuxu usemos para rastrear la migración de todos los demás paquetes. Ver los problemas vinculados.

Bien, lo siento por eso.

¿Deberían cambiarse el nombre de todas las implementaciones de clientes API HTTP ahora a ipfs-http-client?

Parece que algunas implementaciones no siguieron su ejemplo, pero mantener esto abierto tampoco ayuda demasiado. Sin embargo, recomendamos actualizar el nombre, cuando sea posible.