"बहस एक एसडीके चाहते हैं और अंतर्निहित प्रोटोकॉल को जानना चाहते हैं" के बारे में कुछ बहस प्रतीत होती है (http://www.tbray.org/ongoing/When/199x/1999/08/18/BitsOnTheWire देखें)।तार के बारे में बहस "एसडीके बनाम" बिट्स क्या है?
मुझे वास्तव में यह समझ में नहीं आता कि यह किस बात का जिक्र कर रहा है, या वे पारस्परिक रूप से अनन्य क्यों हैं।
प्रत्येक दृष्टिकोण का दर्शन क्या है और वे क्यों संघर्ष करते हैं?
वे वास्तव में पारस्परिक रूप से अनन्य नहीं हैं। यह निरंतरता का अधिक है, लेकिन सिस्टम के पीछे विकास दर्शन एक छोर या दूसरे की तरफ बढ़ता है।
तार पर अनिवार्य रूप से बिट्स का कहना है कि संचार प्रोटोकॉल इतना आसान है कि इसे बाहरी डेवलपर्स को कुछ अपेक्षाकृत सरल (या यहां तक कि अनौपचारिक) विनिर्देश के माध्यम से वर्णित किया जा सकता है। इसका मतलब है कि सेवा का उपयोग सभी प्रकार के अप्रत्याशित तरीकों से किया जा सकता है, और सेवा उपभोक्ता को आधिकारिक समर्थित प्लेटफार्म नहीं होना चाहिए।
दूसरी तरफ, ऐप्पल और माइक्रोसॉफ्ट जैसे मोनोलिथिक प्रसाद वाली कंपनियां एक और दर्शन चुनने की लक्जरी है, जो एक पूर्ण अंत तक एसडीके का निर्माण करना है। सिद्धांत रूप में यह अंतर्निहित प्रोटोकॉल की जटिलताओं को दूर करके डेवलपर्स के लिए जीवन को आसान बनाता है, साथ ही उत्पाद को अधिक जटिल चीजें करने और डेवलपर त्रुटि को कम करने के लिए उत्पाद को मुक्त करता है। बेशक अभी भी बिट्स हैं, और वे अभी भी तार पर जाते हैं, और वे रिवर्स इंजीनियर हो सकते हैं। हालांकि यह एक प्रोटोकॉल का उपयोग करने के लिए काफी कठिन होगा (परिमाण का आदेश) जिसे समझने के लिए डिज़ाइन किया गया था, विशेष रूप से यदि यह जानबूझकर व्यापारिक हितों को पूरा करने के लिए एन्क्रिप्टेड या एन्क्रिप्टेड किया गया था।
मान लीजिए ग्राहक सी सेवा के लिए एस विक्रेता वी द्वारा प्रदान की यदि आप केवल इतना है एक SDK है बात करने के लिए की जरूरत है, तो आप विक्रेता वी के एसडीके सॉफ्टवेयर ग्राहक सी पर स्थापित करना होगा क्रम दूसरी ओर एस से बात करने में विक्रेता वी दस्तावेजों बिल्कुल कैसे सेवा के लिए S बिट स्तर तक नीचे बात करने के लिए है, तो आप अपने खुद के सॉफ्टवेयर ग्राहक सी पर सेवा करने के लिए सीधे एस
तो ... एसडीके आपको एक अनुवादक देता है और तार-ऑन-तार आपको रोजेटा स्टोन देता है? – Fry
बात करने के लिए लिख सकते हैं हाथ, अगर वे परस्पर होने की जरूरत नहीं है अनन्य, यह सिर्फ इतना है कि कोई भी सेवा प्रदान करने वाले व्यक्ति या तो एसडीके या वायर प्रोटोकॉल पर अपने सार्वजनिक ग्राहक के सामने आने वाले इंटरफेस के रूप में ध्यान केंद्रित करेंगे। आपके पास एक सेवा हो सकती है जो दोनों प्रदान की जाती है, और अपने ग्राहकों को यह चुनने दें कि किस पर ध्यान केंद्रित किया जाए, लेकिन यह एक लक्जरी हो सकता है।
हालांकि कुछ परिस्थितियों में यह जानना उपयोगी होता है कि विशेष रूप से समस्या निवारण के लिए थोड़ा स्तर पर क्या चल रहा है, विक्रेता के एसडीके का उपयोग करके विक्रेता किसी भी भावी बदलाव से अपने एकीकरण को अलग करने का सबसे अच्छा तरीका हो सकता है जो विक्रेता अपने संदेश में कर सकता है संरचना।
यह कहना नहीं है कि नवीनतम एसडीके प्राप्त करने के मामले में कोई असुविधा नहीं होगी, लेकिन कम से कम अगर विक्रेता ने अपना काम सही किया है, तो आपको अपना कोड बदलने के बारे में चिंता करने की ज़रूरत नहीं है, बस अपने नए एसडीके का उपयोग कर।
उदाहरण के लिए हमने आईएसडी नामक एक कंपनी के साथ काम किया है जो भुगतान स्विच उत्पादों में माहिर हैं। हमने उनके एसडीके को कोड किया। हालांकि उनके उत्पाद कुछ संस्करणों के माध्यम से चले गए हैं, हमें सबसे ज्यादा करना है कि क्लाइंट मशीनों पर डीएलएल अपडेट करें। डीएलएल ने एक ही सार्वजनिक इंटरफेस को बरकरार रखा।
यदि आप एसडीके मार्ग पर जाते हैं, तो this story में होने वाले वायर स्पेक पर बिट्स भी प्रदान करना बहुत महत्वपूर्ण है।
मुझे नहीं लगता कि यह एक असली सवाल है –