Ipfs: *-ipfs-api를 *-ipfs-http-client로 이름을 바꾸세요??

Go는 CoreAPI를 완료하고 클라이언트를 다시 작성할 때 이를 수행할 수 있습니다... (그렇지 않으면 가져오기가 중단됨).

이름을 -client 로 지정하면 주어진 모듈이 IPFS 클라이언트인 것처럼 들립니다(bitswap/etc를 말하지만 아무 것도 제공할 수 없는 것). 명확한 이름을 원하면 더 길더라도 -api-client 를 제안합니다.

흠. 네, 좋은 지적이 있습니다.

나에게 합리적으로 보인다.

-api-client를 고려하고 있다면 -http-client가 더 분명할 수 있다고 생각합니다.

*-ipfs-api 의 이름을 *-ipfs-http-client 로 변경하는 데 동의하면 이 댓글에 좋아요를 눌러주세요.

내 고객 을 위해 탑승했습니다! 나는 아무 것도 깨지지 않도록 경고와 함께 이전 이름을 유지할 수 있습니다.

정족수에 도달한 것 같습니다. :) 이제 모든 곳에서 이름을 바꾸면 됩니다. :)

PHP 라이브러리는 소켓과도 통신할 수 있습니다... 그래서 이름 변경은 💯% 정확하지 않습니다.

@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 Named Pipes, 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 적어도 Java http 클라이언트의 경우 항상 http 클라이언트일 것입니다. 클라이언트가 기반으로 할 수 있는 다른 프로토콜이 있다면 그것은 다른 프로젝트가 될 것입니다. 이미 http와 cmd 라인 기반 호출을 결합한 go 클라이언트의 경우 상황이 다를 수 있습니다.

@ianopolous 나는 Java API 클라이언트가 websockets를 통해 쉽게 작동하도록 만들 수 있다고 확신합니다. 그것들을 모두 다른 패키지로 만드시겠습니까?

@whyrusleeping 웹 소켓 을 사용하는 서비스에 대해 Java SDK를 본 적이 없습니다. 그런 것이 필요하다면 일반 소켓을 사용하겠습니다. 그것이 ipfs에 유용하고 http 클라이언트에 많은 코드 중복이 있었다면 개인적으로 공통 코드를 라이브러리로 제외하고 이상적으로는 프로토콜에 구애받지 않게 만들 것입니다.

동일한 클라이언트에서 두 가지 다른 프로토콜을 혼합하면 혼란과 버그가 발생할 수 있습니다. https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous 지금은 웹 소켓 토론을 보류하고 여러 백엔드 인터페이스(무엇이든 간에)를 지원할 수 있는 클라이언트 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);

BTW – web3j 는 동일한 Java 모듈에서 HTTP, IPC 및 WSS를 지원하며 API가 멋지게 모델링되는 한 이로 인해 추가되는 유일한 부담은 잠재적으로 사용되지 않는 종속성을 가져오는 것입니다.

@raulk

여러 백엔드 인터페이스(무엇이든 간에)를 지원할 수 있는 클라이언트 SDK가 필요하다고 가정합니다.

나는 확실히 그것을 원하지 않습니다. 모든 프로토콜을 동일한 라이브러리에 두는 것은 몇 가지 단점이 있습니다. 소스 및 바이너리 모두에서 라이브러리 크기를 O(N)으로 만듭니다. 여기서 N은 프로토콜 수입니다. 거의 항상 나는 sdk의 단일 프로토콜 구현만을 원하고 90%가 나와 관련이 없어 내 앱을 부풀리지만 쉽게 제거할 수 있는 라이브러리를 갖고 싶지 않습니다. 또한 보안에 관심이 있고 내 종속성을 감사해야 하는 경우 전혀 이유 없이 복잡성과 비용이 크게 증가합니다.

그런 보편적인 클라이언트가 존재해서는 안 된다고 말하는 것이 아닙니다. 사용 사례가 있을 수 있지만 사람들에게 강요해서는 안 됩니다.

@ianopolous 나는 당신이 uber-JAR 모델을 가정하고 있다고 생각합니다. 내가 말하는 것은 그 반대입니다. 즉, 종속성이 모듈 간에 누출되지 않고 최종 사용자가 해당 모듈을 빌드에 추가할 때만 끌어오는 다중 모듈 빌드입니다. 예를 들어 다양한 기술에 대해 200개 이상의 어댑터를 호스팅하는 Apache Camel 프로젝트를 확인할 수 있습니다. 사용자로서 나는 camel-core(매우 슬림함) + 사용하려는 구성 요소(camel-mqtt, camel-ftp 등)를 추가하고 Maven/Gradle이 나를 위해 효과적인 종속성 그래프를 계산하도록 합니다.

http-client 로 이름을 바꾸는 것에 반대합니다. php-api-client 가 html 끝점이나 소켓과 통신할 수 있기 전에 말했듯이. 다른 드라이버 일 뿐이고 나머지 코드는 완전히 동일합니다. 그래서 저는 http-* 가 원시가 아니라는 입장입니다. 하지만 LANG-ipfs-client 또는 LANG-ipfs-api-client 로 이름을 바꿔도 괜찮습니다.

@digitalkaoz 에 전적으로 동의합니다. 주어진 클라이언트 라이브러리에서 다른 전송을 지원하는지 여부에 따라 다릅니다. (이 문제에 대한 Python 라이브러리는 이미 플러그형 전송이 있고 스크립팅 언어에서 선택적 종속성을 쉽게 가질 수 있기 때문에 그럴 가능성이 높습니다.)

완료되었습니다. 폐쇄.

@Kubuxu 다른 모든 패키지의 마이그레이션을 추적하는 데 사용하겠습니다. 연결된 문제를 참조하십시오.

알겠습니다. 죄송합니다.

모든 HTTP API 클라이언트 구현은 이제 ipfs-http-client로 이름을 변경해야 합니까?

몇 가지 구현이 적합하지 않은 것 같지만 이것을 열어 두는 것도 큰 도움이 되지 않습니다. 가능하면 이름을 업데이트하는 것이 좋습니다.