Ipfs: ganti nama *-ipfs-api menjadi *-ipfs-http-client ??

Go dapat melakukan ini ketika kami menyelesaikan CoreAPI dan menulis ulang klien... (jika tidak, kami akan menghentikan impor).

Memberi nama -client membuatnya terdengar seperti modul yang diberikan adalah klien IPFS (sesuatu yang berbicara bitswap/etc tetapi tidak dapat melayani apa pun). Jika Anda ingin memiliki nama yang jelas, saya sarankan -api-client meskipun lebih panjang.

Hm. Ya, Anda punya poin bagus.

Tampaknya masuk akal bagi saya.

Jika kita mempertimbangkan -api-client, saya pikir -http-client mungkin lebih jelas.

jempol komentar ini jika Anda setuju dengan mengubah nama *-ipfs-api menjadi *-ipfs-http-client

Saya siap untuk klien saya ! Saya mungkin menyimpan nama lama dengan peringatan untuk memastikan tidak merusak apa pun.

Sepertinya kita sudah mencapai kuorum :) Sekarang kita hanya perlu mengganti namanya di mana-mana :)

Pustaka PHP juga dapat berbicara dengan Socket... jadi penggantian nama tidak akan % benar

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

mengapa tidak hanya 'ipfs-api-client'? mengikatnya ke http secara khusus tampaknya ... bertentangan

@whyrusleeping Saat ini hanya http, yang sebenarnya mengejutkan saya ketika saya pertama kali memulai IPFS. Saya senang bahwa sekarang sudah jelas bahwa saat ini klien biasanya menggunakan protokol HTTP.

Sepertinya saya tidak memiliki izin untuk mengganti nama, https://github.com/ipfs/Java-ipfs-api
Dapatkah seseorang memberikannya kepada saya?

@ianopolous menjadikan Anda seorang admin :)

Dua sen dari seseorang di galaksi yang jauh (tidak juga, libp2p)...

ipfs-api-client berlebihan bagi saya karena: bagaimana lagi klien akan berbicara dengan layanan jika tidak melalui API (apa pun antarmuka dan format kabelnya)? EDIT: baca saja komentar @alexander255 di atas, dan itu masuk akal juga. -api-client memperjelas bahwa ini adalah SDK, bukan aplikasi klien.

Termasuk jenis antarmuka aktual (http) dalam namanya adalah IMO picik:

1. Kami tidak ingin mengatur penggantian nama besar-besaran lainnya setelah memperkenalkan dukungan untuk soket Unix, Windows Named Pipes, gRPC, dll.
2. Di masa mendatang, kami mungkin menggunakan pustaka RPC libp2p, yang akan menjadi multitransportasi secara default.
3. Apakah layanan dukungan dicapai melalui HTTP, gRPC, soket Unix, dll. API yang menghadap ke depan akan tetap sama. Modul hipotetis ipfs-api-[ipc/http/grpc]-client akan menduplikasi banyak kode.

ipfs-client tampaknya cocok untuk saya, menggunakan desain seperti adaptor untuk memilih backend HTTP, IPC, gRPC sambil mengekspos frontend yang sama.

Dari saran dan argumen sejauh ini saya paling suka ini, tetapi ipfs-client dibaca seolah-olah itu hanya aplikasi/alat. Jika kita dapat berasumsi bahwa ini selalu dalam bentuk perpustakaan, bagaimana dengan ipfs-client-library atau ipfs-client-lib ?

@raulk Bagi saya, hanya ipfs-client terdengar seperti itu benar-benar berisi implementasi klien ipfs. Yang menyesatkan.

Sangat setuju bahwa menempatkan http dalam judul adalah pandangan yang sangat picik. Akan sangat bagus untuk keputusan yang menjangkau jauh seperti ini untuk dilayangkan sedikit lebih banyak sebelum berkomitmen pada mereka secara luas

@whyrusleeping Setidaknya untuk klien Java http akan selalu seperti itu, klien http. Jika ada beberapa protokol lain yang dapat menjadi dasar klien, maka itu akan menjadi proyek yang berbeda. Hal-hal mungkin berbeda untuk klien go, yang sudah menggabungkan http dengan panggilan berbasis baris cmd.

@ianopolous Saya yakin klien Java api dapat dengan mudah dibuat untuk bekerja melalui soket web, membuatnya juga berfungsi melalui soket domain unix juga tampaknya tidak terlalu mengada-ada. Apakah Anda akan membuat semuanya menjadi paket yang berbeda?

@whyrusleeping Saya belum pernah melihat Java SDK untuk layanan apa pun yang menggunakan soket web, jika saya memang membutuhkan sesuatu seperti itu, saya hanya akan menggunakan soket normal. Jika itu adalah hal yang berguna untuk ipfs, dan ada banyak duplikasi kode dengan klien http, maka secara pribadi saya akan memasukkan kode umum ke dalam perpustakaan (dan idealnya membuatnya lebih protokol agnostik).

Perhatikan bahwa mencampur dua protokol berbeda di klien yang sama dapat menciptakan kemungkinan kebingungan dan bug: https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous Mari kita memarkir diskusi soket web untuk saat ini dan menganggap kita menginginkan SDK klien yang dapat mendukung banyak antarmuka backend (apa pun itu).

Untuk memodelkan ini di Java, Anda biasanya memiliki modul core yang mendefinisikan kerangka, API publik, abstraksi, DTO, dll. Dan kemudian Anda akan memiliki sejumlah modul yang masing-masing menambahkan dukungan untuk backend yang berbeda protokol. Mereka semua mengimplementasikan antarmuka adaptor dari core .

Anda biasanya mengimpor ini ke dalam build dengan <scope>runtime</scope> (Maven), dan core bahkan mungkin menggunakan mekanisme seperti SPI (Antarmuka Penyedia Layanan) untuk menemukan adaptor mana yang tersedia saat runtime, dan gunakan yang optimal (bahkan melakukan semacam fallback atau negosiasi). Atau Anda dapat mengandalkan pengguna untuk menentukan mana yang akan digunakan pada waktu kompilasi, mis

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

BTW – web3j mendukung HTTP, IPC, dan WSS dalam modul Java yang sama, dan selama API dimodelkan dengan baik, satu-satunya beban yang ditambahkan ini adalah menarik dependensi yang berpotensi tidak digunakan.

@raulk

asumsikan kami menginginkan SDK klien yang dapat mendukung beberapa antarmuka backend (apa pun itu).

Saya pasti tidak menginginkan itu. Menempatkan semua protokol di perpustakaan yang sama memiliki beberapa kelemahan. Itu membuat ukuran perpustakaan baik dalam sumber dan biner O(N) di mana N adalah jumlah protokol. Hampir sepanjang waktu saya hanya ingin satu implementasi protokol SDK, dan saya lebih suka tidak memiliki perpustakaan di mana 90% tidak ada bagi saya, membuat aplikasi saya membengkak, tetapi tidak memberi saya cara mudah untuk menghapusnya. Juga jika saya peduli dengan keamanan dan perlu mengaudit dependensi saya, itu merupakan ledakan besar dalam kompleksitas dan biaya tanpa alasan sama sekali.

Saya tidak mengatakan klien universal seperti itu seharusnya tidak ada. Mungkin ada kasus penggunaan untuk itu, tetapi tidak boleh dipaksakan pada orang.

@ianopolous Saya pikir Anda mengasumsikan model uber-JAR. Apa yang saya bicarakan adalah kebalikannya: multi-modul build , di mana dependensi tidak bocor di seluruh modul dan hanya ditarik ketika pengguna akhir menambahkan modul itu ke build mereka. Sebagai contoh, Anda dapat melihat proyek Apache Camel , yang menampung lebih dari 200 adaptor untuk berbagai teknologi. Sebagai pengguna, saya menambahkan camel-core (sangat ramping) + komponen yang ingin saya gunakan (camel-mqtt, camel-ftp, dll.) dan membiarkan Maven/Gradle menghitung grafik ketergantungan yang efektif untuk saya.

saya menentang mengganti namanya menjadi http-client . seperti yang saya katakan sebelumnya php-api-client dapat berbicara ke titik akhir html atau ke soket. itu hanya driver lain, sisa kodenya benar-benar sama. jadi saya berpihak bahwa http-* tidak berpandangan jauh ke depan. tapi saya baik-baik saja dengan mengganti nama menjadi LANG-ipfs-client atau LANG-ipfs-api-client

Saya sepenuhnya setuju dengan @digitalkaoz : Itu tergantung, saya kira, apakah perpustakaan klien yang diberikan membayangkan mendukung transportasi lain atau tidak. (Library Python dalam hal ini kemungkinan besar akan melakukannya, karena sudah memiliki transport yang dapat dicolokkan dan kita dapat dengan mudah memiliki dependensi opsional dalam bahasa skrip.)

Ini dilakukan. Penutupan.

@Kubuxu mari kita gunakan untuk melacak migrasi semua paket lainnya. Lihat masalah terkait.

Oke, maaf soal itu.

Haruskah semua implementasi klien HTTP API mengganti namanya sendiri sekarang menjadi ipfs-http-client?

Tampaknya beberapa implementasi tidak mengikutinya, tetapi membiarkan ini tetap terbuka juga tidak banyak membantu. Kami menyarankan untuk memperbarui nama, jika memungkinkan.