Ipfs: renomeie *-ipfs-api para *-ipfs-http-client ??

Go pode fazer isso quando terminarmos o CoreAPI e reescrevermos o cliente... (caso contrário, quebramos as importações).

Nomeá-lo -client faz parecer que o módulo fornecido é um cliente IPFS (algo que fala bitswap/etc, mas não pode servir a nada). Se você quiser que ele tenha um nome inequívoco, eu sugiro -api-client embora seja mais longo.

Hum. Sim, você tem um bom ponto.

Parece-me razoável.

Se estamos considerando -api-client, acho que -http-client pode ser mais óbvio.

Gostei deste comentário se você concorda em renomear *-ipfs-api para *-ipfs-http-client

Estou a bordo para o meu cliente ! Eu poderia manter o nome antigo com um aviso para ter certeza de não quebrar nada.

Parece que atingimos um quórum :) Agora só precisamos renomeá-los em todos os lugares :)

A biblioteca PHP também pode falar com um Socket... então uma renomeação não seria 💯% correta

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

por que não apenas 'ipfs-api-client'? vinculá-lo a http especificamente parece ... antitético

@whyrusleeping Atualmente é apenas http, o que realmente me surpreendeu quando comecei no IPFS. Fico feliz que esteja claro agora que, no momento, os clientes costumam usar o protocolo HTTP.

Parece que não tenho permissões para renomear, https://github.com/ipfs/java-ipfs-api
Alguém pode me conceder?

@ianopolous fez de você um administrador :)

Dois centavos de alguém em uma galáxia muito distante (não realmente, libp2p)...

ipfs-api-client é redundante para mim porque: de que outra forma um cliente falaria com um serviço se não através de uma API (qualquer que seja a interface e o formato do fio)? EDIT: basta ler o comentário de @alexander255 acima, e também faz sentido. -api-client deixa mais claro que este é um SDK, não um aplicativo cliente.

Incluir o tipo de interface real (http) no nome é IMO míope:

1. Não queremos orquestrar outra renomeação massiva depois de introduzir suporte para soquetes Unix, Windows Named Pipes, gRPC, etc.
2. No futuro poderemos usar uma biblioteca RPC libp2p, que será multitransporte por padrão.
3. Se o serviço de apoio for alcançado via HTTP, gRPC, soquetes Unix, etc., a API frontal permanecerá a mesma. Módulos ipfs-api-[ipc/http/grpc]-client hipotéticos duplicariam muito código.

ipfs-client parece apropriado para mim, usando um design semelhante a um adaptador para escolher back-ends HTTP, IPC, gRPC enquanto expõe o mesmo front-end.

Das sugestões e argumentos até agora eu gosto deste o melhor, mas ipfs-client parece ser apenas um aplicativo/ferramenta. Se podemos assumir que estes estão sempre na forma de bibliotecas que tal ipfs-client-library ou ipfs-client-lib ?

@raulk Para mim, apenas ipfs-client parece que realmente contém a implementação do cliente de ipfs. O que é enganoso.

Concordo fortemente que colocar http no título é super míope. Seria ótimo que decisões de longo alcance como essa fossem divulgadas um pouco mais antes de se comprometer com elas tão amplamente

@whyrusleeping Pelo menos para o cliente http Java sempre será apenas isso, um cliente http. Se houver algum outro protocolo no qual um cliente possa se basear, esse seria um projeto diferente. As coisas podem ser diferentes para o cliente go, que já combina http com chamadas baseadas em linha cmd.

@ianopolous , tenho certeza de que o cliente java api pode ser facilmente feito para funcionar em websockets, fazendo com que também funcione por meio de um soquete de domínio unix também não parece muito forçado. Você faria tudo isso em pacotes diferentes?

@whyrusleeping Eu nunca vi um sdk java para nenhum serviço que usasse websockets, se eu precisasse de algo assim, usaria apenas um soquete normal. Se isso fosse uma coisa útil para o ipfs, e houvesse muita duplicação de código com o cliente http, então pessoalmente eu fatoraria o código comum em uma biblioteca (e idealmente torná-lo ainda mais agnóstico de protocolo).

Observe que misturar dois protocolos diferentes no mesmo cliente pode criar possibilidade de confusão e bugs: https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous Vamos estacionar a discussão sobre websockets por enquanto e assumir que queremos SDKs de cliente que possam suportar várias interfaces de back-end (quaisquer que sejam).

Para modelar isso em Java, você normalmente teria um módulo core que define o esqueleto, API pública, abstrações, DTOs, etc. E então você teria qualquer número de módulos, cada um adicionando suporte para um backend diferente protocolo. Todos eles implementam uma interface de adaptador de core .

Você normalmente os importaria para a compilação com <scope>runtime</scope> (Maven), e core pode até usar um mecanismo como SPI (Service Provider Interface) para descobrir quais adaptadores estão disponíveis em tempo de execução e usar o ideal (mesmo realizando algum tipo de fallback ou negociação). Ou você pode confiar no usuário para especificar qual usar em tempo de compilação, por exemplo

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

BTW – web3j suporta HTTP, IPC e WSS no mesmo módulo Java, e desde que a API seja bem modelada, o único fardo que isso adiciona é puxar dependências potencialmente não utilizadas.

@raulk

suponha que queremos SDKs de cliente que possam suportar várias interfaces de back-end (quaisquer que sejam).

Eu definitivamente não quero isso. Colocar todos os protocolos na mesma biblioteca tem várias desvantagens. Faz o tamanho da biblioteca tanto na fonte quanto no binário O(N) onde N é o número de protocolos. Quase o tempo todo eu só quero uma implementação de protocolo único de um SDK, e prefiro não ter uma biblioteca onde 90% seja estranho para mim, inchando meu aplicativo, mas não me deixando uma maneira fácil de removê-lo. Além disso, se eu me preocupo com a segurança e preciso auditar minhas dependências, isso é uma grande explosão de complexidade e despesa sem motivo algum.

Não estou dizendo que um cliente tão universal não deveria existir. Talvez haja um caso de uso para isso, mas não deve ser forçado às pessoas.

@ianopolous Acho que você está assumindo um modelo uber-JAR. O que estou falando é o oposto: uma compilação de vários módulos , onde as dependências não vazam entre os módulos e são puxadas apenas quando o usuário final adiciona esse módulo à sua compilação. Por exemplo, você pode conferir o projeto Apache Camel , que hospeda mais de 200 adaptadores para diferentes tecnologias. Como usuário, adiciono camel-core (muito fino) + os componentes que quero usar (camel-mqtt, camel-ftp, etc.) e deixo o Maven/Gradle calcular o gráfico de dependência efetiva para mim.

sou contra renomeá-lo para http-client . como eu disse antes, o php-api-client pode falar com um endpoint html ou com um soquete. é apenas outro driver , o resto do código é completamente o mesmo. então estou do lado de que http-* não é clarividente. mas estou bem em renomear para LANG-ipfs-client ou LANG-ipfs-api-client

Eu concordo plenamente com @digitalkaoz : Depende, eu acho, se a biblioteca cliente prevê suporte a outros transportes ou não. (A biblioteca Python provavelmente terá, uma vez que já possui transportes conectáveis ​​e podemos facilmente ter dependências opcionais em linguagens de script.)

Isso foi feito. Fechamento.

@Kubuxu vamos usar para rastrear a migração de todos os outros pacotes. Veja os problemas vinculados.

Ok, desculpe por isso.

Todas as implementações de cliente de API HTTP devem ser renomeadas agora para ipfs-http-client?

Parece que algumas implementações não seguiram o exemplo, mas manter isso aberto também não ajuda muito. Recomendamos atualizar o nome, porém, quando possível.