Ipfs: إعادة تسمية * -ipfs-api إلى * -ipfs-http-client ؟؟

يمكن لـ Go القيام بذلك عندما ننتهي من CoreAPI ونعيد كتابة العميل ... (وإلا فإننا نكسر الواردات).

تسميته -client يجعل الأمر يبدو وكأن الوحدة المعينة هي عميل IPFS (شيء يتحدث bitswap / إلخ ولكن لا يمكن أن يخدم أي شيء). إذا كنت تريد أن يكون له اسم لا لبس فيه ، فأنا أقترح -api-client رغم أنه أطول.

جلالة الملك. نعم ، لديك وجهة نظر جيدة.

يبدو معقولا بالنسبة لي.

إذا كنا نفكر في -api-client أعتقد أن -http-client قد يكون أكثر وضوحًا.

الإعجاب بهذا التعليق إذا كنت توافق على إعادة تسمية *-ipfs-api إلى *-ipfs-http-client

أنا على متن الطائرة لعميلي ! قد احتفظ بالاسم القديم مع تحذير للتأكد من عدم كسر أي شيء.

يبدو أننا وصلنا إلى النصاب القانوني :) الآن نحتاج فقط إلى إعادة تسميتهم في كل مكان :)

يمكن لمكتبة PHP أيضًا التحدث مع Socket ... لذا فإن إعادة التسمية لن تكون٪ صحيحة

منشور مدونة بواسطة 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 مشرفًا :)

سنتان من شخص ما في مجرة ​​بعيدة (ليس في الحقيقة ، libp2p) ...

ipfs-api-client زائد عن الحاجة للأسباب التالية: كيف سيتحدث العميل مع خدمة ما لم يكن ذلك عبر واجهة برمجة التطبيقات (أيًا كانت الواجهة وتنسيق السلك)؟ تحرير: فقط اقرأ تعليق @ alexander255 أعلاه ، وهو أمر منطقي أيضًا. يوضح -api-client أن هذا هو SDK ، وليس تطبيق عميل.

تضمين نوع الواجهة الفعلية (http) في الاسم IMO قصير النظر:

1. لا نريد تنظيم إعادة تسمية ضخمة أخرى بعد تقديم دعم لمآخذ Unix و Windows Named Pipes و gRPC وما إلى ذلك.
2. في المستقبل قد نستخدم مكتبة libp2p RPC ، والتي ستكون نقل متعدد بشكل افتراضي.
3. سواء تم الوصول إلى خدمة الدعم عبر HTTP ، أو gRPC ، أو مقابس Unix ، وما إلى ذلك ، ستظل واجهة برمجة التطبيقات الأمامية كما هي. الوحدات الافتراضية 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. إذا كان هناك بروتوكول آخر يمكن أن يعتمد عليه العميل ، فسيكون هذا مشروعًا مختلفًا. قد تكون الأمور مختلفة بالنسبة لعميل go ، الذي يدمج بالفعل http مع المكالمات المستندة إلى سطر cmd.

ianopolous ، أنا متأكد من أنه يمكن جعل عميل java api يعمل بسهولة عبر مآخذ الويب ، مما يجعله يعمل أيضًا عبر مقبس مجال unix لا يبدو بعيد المنال أيضًا. هل ستجعل كل ذلك في حزم مختلفة؟

whyrusleeping لم أشاهد مطلقًا java sdk لأي خدمة تستخدم مآخذ ويب ، إذا كنت بحاجة إلى شيء من هذا القبيل ، فسأستخدم مقبسًا عاديًا. إذا كان هذا شيئًا مفيدًا لـ ipfs ، وكان هناك الكثير من تكرار الكود مع عميل http ، فأنا شخصياً سأقوم بإخراج الكود المشترك في مكتبة (ومن الأفضل جعله أكثر حيادية للبروتوكول).

لاحظ أن خلط بروتوكولين مختلفين في نفس العميل يمكن أن يخلق إمكانية حدوث ارتباك وأخطاء: https://github.com/ipfs/go-ipfs/issues/5784

ianopolous ، دعنا نوقف مناقشة websockets في الوقت الحالي ونفترض أننا نريد مجموعات SDK للعميل يمكنها دعم واجهات متعددة للخلفية (مهما كانت).

لنمذجة هذا في Java ، سيكون لديك عادةً وحدة core التي تحدد الهيكل العظمي وواجهة برمجة التطبيقات العامة والتجريد و DTOs وما إلى ذلك. وبعد ذلك سيكون لديك أي عدد من الوحدات يضيف كل منها دعمًا لواجهة خلفية مختلفة بروتوكول. كلهم يطبقون واجهة محول من core .

يمكنك عادةً استيرادها إلى الإصدار باستخدام <scope>runtime</scope> (Maven) ، و core قد تستخدم آلية مثل SPI (واجهة مزود الخدمة) لاكتشاف المحولات المتوفرة في وقت التشغيل ، واستخدامها الخيار الأمثل (حتى إجراء نوع من الإجراءات الاحتياطية أو التفاوض). أو يمكنك الاعتماد على المستخدم لتحديد أي واحد لاستخدامه في وقت الترجمة ، على سبيل المثال

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

راجع للشغل - يدعم web3j HTTP و IPC و WSS في نفس وحدة Java ، وطالما تم تصميم واجهة برمجة التطبيقات بشكل جيد ، فإن العبء الوحيد الذي يضيفه هذا هو سحب التبعيات غير المستخدمة.

تضمين التغريدة

لنفترض أننا نريد مجموعات SDK للعميل يمكنها دعم واجهات متعددة للخلفية (مهما كانت).

أنا بالتأكيد لا أريد ذلك. إن وضع جميع البروتوكولات في نفس المكتبة له عدة جوانب سلبية. يجعل حجم المكتبة في كل من المصدر والثنائي O (N) حيث N هو عدد البروتوكولات. في جميع الأوقات تقريبًا ، أرغب فقط في تطبيق بروتوكول واحد لـ sdk ، وأنا أفضل ألا أمتلك مكتبة بنسبة 90٪ غريبة بالنسبة لي ، مما يؤدي إلى تضخيم تطبيقي ، ولكن لا يترك لي طريقة سهلة لإزالته. أيضًا إذا كنت مهتمًا بالأمان وأحتاج إلى مراجعة تبعياتي ، فهذا انفجار ضخم في التعقيد والنفقات بدون سبب على الإطلاق.

أنا لا أقول أن مثل هذا العميل العالمي لا ينبغي أن يكون موجودًا. ربما هناك حالة استخدام لها ، لكن لا ينبغي فرضها على الناس.

ianopolous أعتقد أنك تفترض نموذج uber-JAR. ما أتحدث عنه هو العكس: بناء متعدد الوحدات ، حيث لا تتسرب التبعيات عبر الوحدات ولا يتم سحبها إلا عندما يضيف المستخدم النهائي تلك الوحدة إلى بنائها. على سبيل المثال ، يمكنك التحقق من مشروع Apache Camel ، الذي يستضيف أكثر من 200 محول لتقنيات مختلفة. كمستخدم ، أقوم بإضافة جوهر الجمل (نحيف جدًا) + المكونات التي أرغب في استخدامها (camel-mqtt ، camel-ftp ، إلخ) ودع Maven / Gradle يحسب الرسم البياني الفعال للتبعية بالنسبة لي.

أنا ضد إعادة تسميته إلى http-client . كما قلت من قبل يمكن للعميل php-api التحدث إلى نقطة نهاية html أو إلى مقبس. إنه مجرد سائق آخر ، أما باقي الشفرة فهي نفسها تمامًا. لذلك أنا على الجانب أن http-* ليس بعيد النظر. لكنني على ما يرام مع إعادة التسمية إلى LANG-ipfs-client أو LANG-ipfs-api-client

أتفق تمامًا مع digitalkaoz : هذا يعتمد ، على ما أعتقد ، على ما إذا كانت تصورات مكتبة العميل تدعم وسائل النقل الأخرى أم لا. (من المحتمل أن تكون مكتبة Python لهذه المسألة كذلك ، نظرًا لأنها تحتوي بالفعل على وسائل نقل قابلة للتوصيل ويمكننا بسهولة الحصول على تبعيات اختيارية في لغات البرمجة النصية.)

تم ذلك. إغلاق.

Kubuxu دعونا نستخدم لتتبع ترحيل جميع الحزم الأخرى. انظر القضايا المرتبطة.

حسنا آسف على ذلك.

هل يجب أن تعيد جميع تطبيقات عميل واجهة برمجة تطبيقات HTTP تسمية نفسها الآن إلى ipfs-http-client؟

يبدو أن بعض التطبيقات لم تحذو حذوها ، لكن إبقاء هذا مفتوحًا لا يساعد كثيرًا أيضًا. نوصي بتحديث الاسم رغم ذلك ، عندما يكون ذلك ممكنًا.