Ipfs: नाम बदलें *-ipfs-api से *-ipfs-http-client ??

जब हम CoreAPI को समाप्त करते हैं और क्लाइंट को फिर से लिखते हैं, तो हम ऐसा कर सकते हैं ... (अन्यथा, हम आयात को तोड़ देते हैं)।

इसे -client नाम देने से ऐसा लगता है जैसे दिया गया मॉड्यूल एक आईपीएफएस क्लाइंट है (ऐसा कुछ जो बिट्सवैप/आदि से बात करता है लेकिन कुछ भी नहीं दे सकता)। यदि आप चाहते हैं कि इसका एक स्पष्ट नाम हो, तो मेरा सुझाव है कि -api-client हालांकि यह लंबा है।

हम्म। हाँ, आपके पास एक अच्छी बात है।

मेरे लिए उचित लगता है।

अगर हम -एपीआई-क्लाइंट पर विचार कर रहे हैं तो मुझे लगता है कि -http-क्लाइंट अधिक स्पष्ट हो सकता है।

यदि आप *-ipfs-api *-ipfs-http-client करने से सहमत हैं तो इस टिप्पणी को पसंद करें

मैं अपने मुवक्किल के लिए बोर्ड पर हूँ! मैं पुराने नाम को चेतावनी के साथ रख सकता हूं ताकि यह सुनिश्चित हो सके कि मैं कुछ भी नहीं तोड़ूंगा।

ऐसा लगता है कि हम एक कोरम पर पहुंच गए हैं :) अब हमें बस हर जगह उनका नाम बदलने की जरूरत है :)

PHP पुस्तकालय सॉकेट के साथ भी बात कर सकता है ... इसलिए एक नाम बदलना 💯% सही नहीं होगा

@alanshaw द्वारा ब्लॉग पोस्ट https://blog.ipfs.io/58-http-client-rename/ \o/

सिर्फ 'आईपीएफएस-एपीआई-क्लाइंट' क्यों नहीं? इसे http से बांधना विशेष रूप से लगता है ... विरोधी

@whyrusleeping वर्तमान में यह केवल http है, जिसने वास्तव में मुझे आश्चर्यचकित कर दिया जब मैंने पहली बार आईपीएफएस पर शुरुआत की। मुझे खुशी है कि अब यह स्पष्ट हो गया है कि फिलहाल क्लाइंट आमतौर पर HTTP प्रोटोकॉल का उपयोग करते हैं।

ऐसा लगता है कि मेरे पास नाम बदलने की अनुमति नहीं है, https://github.com/ipfs/java-ipfs-api
क्या कोई उन्हें मुझे दे सकता है?

@ianopolous ने आपको एक व्यवस्थापक बना दिया :)

दूर आकाशगंगा में किसी से दो सेंट (वास्तव में नहीं, libp2p) ...

ipfs-api-client मेरे लिए बेमानी है क्योंकि: क्लाइंट किसी सेवा से कैसे बात करेगा यदि एपीआई के माध्यम से नहीं (इंटरफ़ेस और वायर प्रारूप जो भी हो)? संपादित करें: बस ऊपर @ alexander255 की टिप्पणी पढ़ें, और यह भी समझ में आता है। -api-client यह स्पष्ट करता है कि यह एक एसडीके है, क्लाइंट एप्लिकेशन नहीं।

नाम में वास्तविक इंटरफ़ेस प्रकार (http) को शामिल करना अदूरदर्शी IMO है:

1. यूनिक्स सॉकेट्स, विंडोज नेम्ड पाइप्स, जीआरपीसी, आदि के लिए समर्थन शुरू करने के बाद हम एक और बड़े नाम का आयोजन नहीं करना चाहते हैं।
2. भविष्य में हम एक libp2p RPC लाइब्रेरी का उपयोग कर सकते हैं, जो डिफ़ॉल्ट रूप से मल्टीट्रांसपोर्ट होगी।
3. क्या बैकिंग सेवा HTTP, gRPC, यूनिक्स सॉकेट्स, आदि के माध्यम से प्राप्त की जाती है, फ्रंट-फेसिंग 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 कम से कम जावा http क्लाइंट के लिए यह हमेशा एक http क्लाइंट होगा। यदि कोई अन्य प्रोटोकॉल है जिस पर क्लाइंट आधारित हो सकता है, तो यह एक अलग परियोजना होगी। गो क्लाइंट के लिए चीजें अलग हो सकती हैं, जो पहले से ही http को cmd लाइन आधारित कॉल के साथ जोड़ती है।

@ianopolous मुझे यकीन है कि जावा एपीआई क्लाइंट को आसानी से websockets पर काम करने के लिए बनाया जा सकता है, जिससे यह यूनिक्स डोमेन सॉकेट के माध्यम से भी काम करता है, यह बहुत दूर नहीं लगता है। क्या आप उन सभी को अलग-अलग पैकेज में बनाएंगे?

@whyrusleeping मैंने कभी भी किसी भी सेवा के लिए जावा एसडीके नहीं देखा है जो websockets का उपयोग करता है, अगर मुझे ऐसा कुछ चाहिए तो मैं बस एक सामान्य सॉकेट का उपयोग करूंगा। यदि यह ipfs के लिए एक उपयोगी चीज थी, और http क्लाइंट के साथ बहुत सारे कोड दोहराव थे, तो व्यक्तिगत रूप से मैं सामान्य कोड को एक पुस्तकालय में बदल देता (और आदर्श रूप से इसे और भी अधिक प्रोटोकॉल अज्ञेयवादी बना देता)।

ध्यान दें कि एक ही क्लाइंट में दो अलग-अलग प्रोटोकॉल को मिलाने से भ्रम और बग की संभावना पैदा हो सकती है: https://github.com/ipfs/go-ipfs/issues/5784

@ianopolous चलिए अभी के लिए websockets चर्चा को पार्क करते हैं और मान लेते हैं कि हम क्लाइंट SDK चाहते हैं जो कई बैकएंड इंटरफेस (जो कुछ भी हो) का समर्थन कर सके।

जावा में इसे मॉडल करने के लिए, आपके पास सामान्य रूप से core मॉड्यूल होगा जो कंकाल, सार्वजनिक एपीआई, एब्स्ट्रैक्शन, डीटीओ आदि को परिभाषित करता है। और फिर आपके पास एक अलग बैकएंड के लिए समर्थन जोड़ने वाले प्रत्येक मॉड्यूल की संख्या होगी मसविदा बनाना। वे सभी core से एक एडेप्टर इंटरफ़ेस लागू करते हैं।

आप आम तौर पर इन्हें <scope>runtime</scope> (मावेन) के साथ बिल्ड में आयात करते हैं, और core एसपीआई (सर्विस प्रोवाइडर इंटरफेस) जैसे तंत्र का उपयोग यह पता लगाने के लिए भी कर सकते हैं कि कौन से एडेप्टर रनटाइम पर उपलब्ध हैं, और उपयोग करें इष्टतम एक (यहां तक ​​​​कि किसी प्रकार की वापसी या बातचीत का प्रदर्शन)। या आप यह निर्दिष्ट करने के लिए उपयोगकर्ता पर भरोसा कर सकते हैं कि संकलन समय पर किसका उपयोग करना है, उदाहरण के लिए

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

BTW - web3j एक ही जावा मॉड्यूल में HTTP, IPC और WSS का समर्थन करता है, और जब तक API को अच्छी तरह से मॉडल किया जाता है, तब तक यह एकमात्र बोझ संभावित अप्रयुक्त निर्भरता को खींच रहा है।

@raulk

मान लें कि हम क्लाइंट एसडीके चाहते हैं जो कई बैकएंड इंटरफेस (जो कुछ भी हो) का समर्थन कर सके।

मैं निश्चित रूप से ऐसा नहीं चाहता। सभी प्रोटोकॉल को एक ही लाइब्रेरी में रखने से कई कमियां हैं। यह पुस्तकालय के आकार को स्रोत और बाइनरी ओ (एन) दोनों में बनाता है जहां एन प्रोटोकॉल की संख्या है। लगभग हर समय मैं केवल एक एसडीके का एक प्रोटोकॉल कार्यान्वयन चाहता हूं, और मेरे पास एक पुस्तकालय नहीं होगा जहां 90% मेरे लिए अपर्याप्त है, मेरे ऐप को फूला रहा है, लेकिन मुझे इसे हटाने का कोई आसान तरीका नहीं है। इसके अलावा अगर मुझे सुरक्षा की परवाह है और मुझे अपनी निर्भरता का ऑडिट करने की आवश्यकता है जो बिना किसी कारण के जटिलता और खर्च में बहुत बड़ा झटका है।

मैं यह नहीं कह रहा हूं कि ऐसा सार्वभौमिक ग्राहक मौजूद नहीं होना चाहिए। हो सकता है कि इसके लिए कोई उपयोग का मामला हो, लेकिन इसे लोगों पर थोपा नहीं जाना चाहिए।

@ianopolous मुझे लगता है कि आप एक uber-JAR मॉडल मान रहे हैं। मैं जिस बारे में बात कर रहा हूं वह विपरीत है: एक बहु-मॉड्यूल बिल्ड , जहां निर्भरता मॉड्यूल में लीक नहीं होती है और केवल तभी खींची जाती है जब अंतिम उपयोगकर्ता उस मॉड्यूल को अपने निर्माण में जोड़ता है। उदाहरण के लिए, आप अपाचे कैमल प्रोजेक्ट देख सकते हैं, जो विभिन्न तकनीकों के लिए 200 से अधिक एडेप्टर होस्ट करता है। एक उपयोगकर्ता के रूप में, मैं ऊंट-कोर (बहुत पतला) + घटक जो मैं उपयोग करना चाहता हूं (ऊंट-एमक्यूटीटी, ऊंट-एफटीपी, आदि) जोड़ता हूं और मेवेन/ग्रैडल को मेरे लिए प्रभावी निर्भरता ग्राफ की गणना करने देता हूं।

मैं इसका नाम बदलकर http-client करने के खिलाफ हूं। जैसा कि मैंने पहले कहा था कि php-api-client html एंडपॉइंट या सॉकेट से बात कर सकता है। यह सिर्फ एक और ड्राइवर है, बाकी कोड पूरी तरह से समान है। इसलिए मैं इस पक्ष में हूं कि http-* दूरदर्शी नहीं है। लेकिन मैं LANG-ipfs-client या LANG-ipfs-api-client . का नाम बदलने के साथ ठीक हूं

मैं @digitalkaoz से पूरी तरह सहमत हूं: यह निर्भर करता है, मुझे लगता है, कि क्लाइंट लाइब्रेरी अन्य ट्रांसपोर्ट का समर्थन करती है या नहीं। (उस मामले के लिए पायथन लाइब्रेरी की संभावना होगी, क्योंकि इसमें पहले से ही प्लग करने योग्य ट्रांसपोर्ट हैं और हम आसानी से स्क्रिप्टिंग भाषाओं में वैकल्पिक निर्भरता प्राप्त कर सकते हैं।)

यह किया गया था। समापन।

@Kubuxu अन्य सभी पैकेजों के माइग्रेशन को ट्रैक करने के लिए उपयोग करते हैं। जुड़े मुद्दों को देखें।

ठीक है, इसके लिए खेद है।

क्या सभी HTTP API क्लाइंट कार्यान्वयनों का नाम बदलकर अब ipfs-http-क्लाइंट कर दिया जाना चाहिए?

ऐसा लगता है कि कुछ कार्यान्वयन सूट का पालन नहीं करते थे, लेकिन इसे खुला रखने से बहुत ज्यादा मदद नहीं मिलती है। हालांकि, जब भी संभव हो, हम नाम को अपडेट करने की सलाह देते हैं।