मैनेज किए जा रहे नेमस्पेस

खास जानकारी

शुरुआती जानकारी

Weave SDK में मैनेज किए गए नेमस्पेस का इस्तेमाल करके, Weave SDK टूल और इंटिग्रेटर, दोनों को SDK टूल में मौजूद एपीआई सेट के लिए विज्ञापन से जुड़े दिशा-निर्देश और सबटेक्स्ट उपलब्ध कराया जाता है. इसकी मदद से, वे Weave SDK की रिलीज़ में अपने माइग्रेशन पाथ का प्लान बना सकते हैं और उसका अनुमान लगा सकते हैं. साथ ही, दिए गए मॉड्यूल के लिए, एक साथ कई Weave API मैनेज कर सकते हैं.

पद

मैनेज किए जा रहे नेमस्पेस को इन चार में से किसी एक कैटगरी के तौर पर मैनेज किया जा सकता है:

डेवलेपमेंट

डेवलपमेंट लेवल के साथ मैनेज किया जाने वाला कोई भी नेमस्पेस, डेवलपर और इंटिग्रेटर के लिए एक संकेत होता है कि इसमें शामिल एपीआई में फ़िलहाल बदलाव किया जा सकता है और वह आधिकारिक तौर पर काम नहीं करता. आम तौर पर, इंटिग्रेटर को इन एपीआई का इस्तेमाल करने की सलाह तब तक नहीं दी जाती, जब तक कि उन्हें खास तौर से ऐसा करने के लिए न कहा गया हो.

आगे बढ़ें

'आगे बढ़ें' के साथ मैनेज किए जाने वाले सभी नेमस्पेस, डेवलपर और इंटिग्रेटर के लिए एक संकेत होते हैं कि उनमें शामिल एपीआई में, काफ़ी हद तक सक्रिय डेवलपमेंट पूरा होने के बावजूद, उनमें बदलाव हो सकता है. साथ ही, यह शुरुआती आकलन के लिए काम करता है. इस तरह के एपीआई तय किए गए हैं, जो Weave SDK API में अगले बदलाव लाने वाले फ़्रंट को दिखाते हैं. साथ ही, तुरंत से लेकर आने वाले समय में, अहम रिलीज़ साइकल के लिए मौजूदा और डिफ़ॉल्ट एपीआई बन जाएंगे.

एपीआई और ओवर-द-वायर प्रोटोकॉल, दोनों के नज़रिए से पुराने सिस्टम के साथ काम करने की सुविधा हो सकती है, लेकिन एपीआई में इसकी कोई गारंटी नहीं है.

Next में मैनेज किया गया नेमस्पेस तय करने से, डेवलपर और इंटिग्रेटर को यह पता चलता है कि Weave SDK किस ओर ले जा रहा है. इसके लिए, यह बताया जाता है कि आने वाले समय में रिलीज़ होने वाले वर्शन में, कौनसा मौजूदा और डिफ़ॉल्ट एपीआई बन जाएगा.

मैनेज किया जा रहा अगला नेमस्पेस तय करना ज़रूरी नहीं है, ताकि मैनेज किया जा रहा नेमस्पेस उसका इस्तेमाल किए बिना लाइफ़साइकल में ट्रांज़िशन कर सके (मैनेज किया गया नेमस्पेस लाइफ़साइकल देखें).

मौजूदा नाम

किसी मौजूदा नेमस्पेस या मैनेज नहीं किए जा रहे नेमस्पेस के साथ मैनेज किया जाने वाला कोई भी नेमस्पेस (उदाहरण के लिए, मैनेज किए गए नेमस्पेस न होना), Weave SDK के उस हिस्से या मॉड्यूल के लिए मौजूदा, डिफ़ॉल्ट, आधिकारिक एपीआई के बारे में बताता है. हालांकि, इस तरह के एपीआई में अब भी सुधार किए जा रहे हैं, लेकिन कुछ बदलावों के साथ पुराने और बेहतर काम करने की क्षमता में बढ़ोतरी होगी. इसके लिए, एपीआई और ओवर द वायर, दोनों को बनाए रखा जाना चाहिए.

मौजूदा मैनेज किए गए नेमस्पेस का इस्तेमाल करना ज़रूरी नहीं है, ताकि मैनेज किया जा रहा नेमस्पेस उसका इस्तेमाल किए बिना लाइफ़साइकल में ट्रांज़िशन कर सके (मैनेज किया गया नेमस्पेस लाइफ़साइकल देखें). असल में, मैनेज नहीं किया जा रहा कोई भी नेमस्पेस मौजूदा होता है.

विरासती

लेगसी कैटगरी के साथ मैनेज किए जाने वाले किसी भी नेमस्पेस से, डेवलपर और इंटिग्रेटर को पता चलता है कि उनमें शामिल एपीआई अब काम नहीं करते. साथ ही, उनके लिए नया और मौजूदा एपीआई जोड़ दिया जाता है. ये एपीआई पुराने एपीआई के बारे में बताते हैं.

इसलिए, तय किए गए एपीआई, Weave SDK की अगली अहम रिलीज़ के बाद पूरी तरह से हट जाएंगे. इसलिए, अगर डेवलपर और इंटिग्रेटर को Weave SDK की रिलीज़ के सबसे नए वर्शन पर काम जारी रखना है, तो उन्हें इन एपीआई से माइग्रेट करने के लिए प्लान बनाना होगा.

मैनेज किए गए Namespace का लाइफ़साइकल

नीचे दिया गया डायग्राम, मैनेज किए जा रहे नेमस्पेस के लाइफ़साइकल के बारे में बताता है, क्योंकि यह डेवलपमेंट और संभावित रूप से लेगसी में ट्रांज़िशन होता है:

.-------------.      .- - - .      .- - - - -.      .--------.
| Development | -.->   Next   -.->   Current   ---> | Legacy |
'-------------'  |   '- - - '  |   ' - - - - '      '--------'
                 |             |
                 '-------------'

अगर यह ऑपरेट किया जाता है, तो मैनेज किए गए नेमस्पेस का लाइफ़साइकल डेवलपमेंट तय से शुरू होता है.

डेवलपमेंट पूरा होने के बाद कोड, आकलन और इंटिग्रेशन के लिए तैयार हो जाने पर, कैटगरी या तो 'आगे बढ़ें' या 'मौजूदा' पर माइग्रेट हो जाती है. इसके अलावा, इस कैटगरी को पूरी तरह हटाया जा सकता है और मैनेज किया जा रहा नेमस्पेस इस्तेमाल नहीं किया जा सकता. इसकी वजह से, पद को सीधे तौर पर मौजूदा वैल्यू के तौर पर सेट किया जा सकता है.

अगर कोड के साथ रहने के लिए है, लेकिन अभी तक मौजूदा कोड को नहीं बदला गया है, तो पद को Next में माइग्रेट होना चाहिए. अगर कोड को मौजूदा कोड को बदलना है, तो स्टेटस को मौजूदा कोड पर माइग्रेट करना चाहिए.

'अगली' कैटगरी का इस्तेमाल करने पर, कोड के रिलीज़ और आकलन की तय संख्या तक पहुंचने पर वह मौजूदा स्थिति में माइग्रेट हो जाता है. इसके अलावा, यह भी हो सकता है कि पद को पूरी तरह से हटाया जाए.

अगर मौजूदा कोड को नए कोड से बदलना है, लेकिन कई रिलीज़ साइकल तक उसे बनाए रखने की ज़रूरत है, तो मौजूदा स्थिति का इस्तेमाल लेगसी में कर दिया जाता है.

लेगसी कैटगरी में आने पर, कोड को Weave SDK से पूरी तरह हटा दिया जाता है.

मैनेज किए जा रहे नेमस्पेस का इस्तेमाल करना

Weave SDK टूल के उपयोगकर्ता, मैनेज किए गए नेमस्पेस के साथ डेवलपर के तौर पर, मौजूदा कोड को बढ़ाने और बनाए रखने के लिए या इंटिग्रेटर के तौर पर इंटरैक्ट कर सकते हैं. साथ ही, Weave को अपने ऐप्लिकेशन, प्लैटफ़ॉर्म, और सिस्टम कोड में इंटिग्रेट कर सकते हैं. इन दो नज़रियों से Weave की ओर से मैनेज किए गए नेमस्पेस का इस्तेमाल करने के लिए, इन दो सेक्शन में ज़्यादा जानकारी वाले सुझाव दिए गए हैं.

डेवलपर के तौर पर मैनेज किए गए नेमस्पेस का इस्तेमाल करना

Weave SDK टूल के डेवलपर का मुख्य मकसद, नए Weave SDK टूल के एपीआई और फ़ंक्शन को बेहतर बनाना और डेवलप करना है. साथ ही, वे कई मामलों में एक ही समय पर, मौजूदा एपीआई और फ़ंक्शन को डिप्लॉय करने में भी मदद कर रहे हैं.

वहीं, मैनेज किए जा रहे नेमस्पेस एक ही एपीआई में, पुराने सिस्टम के साथ काम करने की सुविधा को बेहतर तरीके से मैनेज कर सकते हैं. हालांकि, मैनेज किए जा रहे नेमस्पेस इन एपीआई को साथ-साथ मैनेज करने का तरीका उपलब्ध कराते हैं. इससे मौजूदा एपीआई और फ़ंक्शन के डिप्लॉयमेंट पर कोई असर नहीं पड़ता.

काम करने वाले उदाहरण के तौर पर, एक Weave प्रोफ़ाइल, Mercury, जो फ़िलहाल मैनेज नहीं की जा रही, नेमस्पेस के नीचे दिए गए हैरारकी में मौजूद है:

namespace nl {
namespace Weave {
namespace Profiles {
namespace Mercury {

// ...

}; // namespace Mercury
}; // namespace Profiles
}; // namespace Weave
}; // namespace nl

और नीचे दिए गए सार्वजनिक हेडर:

  • Weave/Profiles/Mercury/Mercury.hpp
  • Weave/Profiles/Mercury/Bar.hpp
  • Weave/Profiles/Mercury/Foo.hpp
  • Weave/Profiles/Mercury/Foobar.hpp

जहां Mercury.hpp "एंब्रेला" हेडर मॉड्यूल है. जैसा कि दिखाया गया है, ज़्यादातर इंटिग्रेटर में सिर्फ़ "एंब्रेटर" हेडर मॉड्यूल शामिल होता है:

#include 

हालांकि, Mercury का डेवलपर इस मकाम तक पहुंच गया है कि उसे एपीआई की अगली-पीढ़ी की टेक्नोलॉजी डेवलप करने की ज़रूरत है. साथ ही, ऐसा ओवर-द-वायर प्रोटोकॉल भी बनाने की ज़रूरत है जो मौजूदा डिप्लॉयमेंट के साथ पुराने सिस्टम के साथ काम नहीं करता. मैनेज किए जा रहे नेमस्पेस का इस्तेमाल करने से, इन मौजूदा डिप्लॉयमेंट को नुकसान पहुंचाए बिना ऐसा करने में मदद मिल सकती है.

मौजूदा नेमस्पेस को मौजूदा पर ले जाएं

एपीआई के मौजूदा वर्शन और डिप्लॉय किए गए मौजूदा इंटिग्रेशन के फ़ंक्शन को सही तरीके से इस्तेमाल करने के मकसद से, सबसे पहले मौजूदा कोड को माइग्रेट करें:

% cd src/lib/profiles/mercury
% mkdir Current
% mv Mercury.hpp Bar.hpp Foo.hpp Foobar.hpp *.cpp Current/

ध्यान दें, फ़ाइलों को मूव करने के अलावा, हेडर में ले जाई गई फ़ाइलों के लिए गार्ड का नाम भी बदला जाना चाहिए. ऐसा होने पर, फ़ाइलों को '_CURRENT' से सजा दिया जाएगा. ऐसा इसलिए, क्योंकि उनके नाम वाली नई फ़ाइलें ही नीचे बनाई जाएंगी.

कोड को दूसरी जगह ले जाने के बाद, अगला चरण है नेमस्पेस को सही कैटगरी में मैनेज करना. यह जानकारी यहां 'Current' के तौर पर दी गई है. सबसे पहले, ऐसा हेडर बनाएं जो मैनेज किए गए नेमस्पेस को 'Current/MercurymanagedNamespace.hpp' के रूप में परिभाषित करता है. इस तरह के हेडर बनाने से बेहतर है कि जब एक से ज़्यादा हेडर फ़ाइलें हों, तो इस कॉन्टेंट को हर हेडर फ़ाइल में दोहराया या डुप्लीकेट किया जाए.

% cat << EOF > Current/MercuryManagedNamespace.hpp
#ifndef _WEAVE_MERCURY_MANAGEDNAMESPACE_CURRENT_HPP
#define _WEAVE_MERCURY_MANAGEDNAMESPACE_CURRENT_HPP

#include 

#if defined(WEAVE_CONFIG_MERCURY_NAMESPACE) && WEAVE_CONFIG_MERCURY_NAMESPACE != kWeaveManagedNamespace_Current
#error Compiling Weave Mercury current-designation managed namespace file with WEAVE_CONFIG_MERCURY_NAMESPACE defined != kWeaveManagedNamespace_Current
#endif

#ifndef WEAVE_CONFIG_MERCURY_NAMESPACE
#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Current
#endif

namespace nl {
namespace Weave {
namespace Profiles {

namespace WeaveMakeManagedNamespaceIdentifier(Mercury, kWeaveManagedNamespaceDesignation_Current) { };

namespace Mercury = WeaveMakeManagedNamespaceIdentifier(Mercury, kWeaveManagedNamespaceDesignation_Current);

}; // namespace Profiles
}; // namespace Weave
}; // namespace nl

#endif // _WEAVE_MERCURY_MANAGEDNAMESPACE_CURRENT_HPP
EOF

इसके बाद, इस हेडर को मौजूदा हेडर में किसी अन्य मॉड्यूल के लिए खास तौर पर शामिल निर्देशों को शामिल करने से पहले शामिल करें. उदाहरण के लिए:

#include 

#include 

कम्पैटबिलटी हेडर बनाएं

हालांकि, मौजूदा हेडर को किसी नई जगह पर ले जाना और सिर्फ़ उनके नेमस्पेस को मैनेज करना, यह पक्का करने के लिए काफ़ी नहीं है कि मौजूदा डिप्लॉयमेंट बिना किसी बदलाव के काम करेंगे, क्योंकि वे सभी शामिल करने वाले निर्देशों का इस्तेमाल कर रहे हैं. ये हेडर ऊपर बताए गए हैं.

इसे ठीक करने के लिए, हाल ही में ट्रांसफ़र किए गए नामों के साथ कम्पैटबिलटी रैपर हेडर बनाना ज़रूरी है.

% touch Mercury.hpp Bar.hpp Foo.hpp Foobar.hpp

अगर डेवलपमेंट- या अगले-तय किए गए मैनेज किए जा रहे नेमस्पेस को बनाए बिना ही, सिर्फ़ मौजूदा के तौर पर मैनेज किया जा रहा नेमस्पेस बनाया जा रहा है, तो इन फ़ाइलों के कॉन्टेंट में एक हेडर शामिल हो सकता है. इसमें एक हेडर शामिल हो सकता है. साथ ही, उसी नाम के हाल ही में ले जाए गए हेडर को शामिल करने वाला डायरेक्टिव भी शामिल हो सकता है:

#ifndef _WEAVE_MERCURY_BAR_HPP
#define _WEAVE_MERCURY_BAR_HPP

#include 

#endif // _WEAVE_MERCURY_BAR_HPP

हालांकि, अगर नए, असंगत डेवलपमेंट को शामिल करने के लिए डेवलपमेंट- या अगले-तय किए गए मैनेज किए गए नेमस्पेस भी बनाया जा रहा है, तो कुछ और जटिल करने की ज़रूरत है.

पहले की तरह ही, मैनेज किए गए नेमस्पेस के कॉन्फ़िगरेशन के लिए एक हेडर बनाया जाता है. इसे यहां MercurymanagedNamespace.hpp के तौर पर बनाया जाता है. ध्यान दें, कई हेडर फ़ाइलें होने पर हर हेडर फ़ाइल में इस कॉन्टेंट को दोहराने और डुप्लीकेट बनाने को प्राथमिकता दी जाती है.

% cat << EOF > MercuryManagedNamespace.hpp
#ifndef _WEAVE_MERCURY_MANAGEDNAMESPACE_HPP
#define _WEAVE_MERCURY_MANAGEDNAMESPACE_HPP

#include 

#if defined(WEAVE_CONFIG_MERCURY_NAMESPACE)                             \
  && (WEAVE_CONFIG_MERCURY_NAMESPACE != kWeaveManagedNamespace_Current) \
  && (WEAVE_CONFIG_MERCURY_NAMESPACE != kWeaveManagedNamespace_Development)
#error "WEAVE_CONFIG_MERCURY_NAMESPACE defined, but not as namespace kWeaveManagedNamespace_Current or kWeaveManagedNamespace_Development"
#endif

#if !defined(WEAVE_CONFIG_MERCURY_NAMESPACE)
#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Current
#endif

#endif // _WEAVE_MERCURY_MANAGEDNAMESPACE_HPP
EOF

ध्यान दें कि अगर कोई कॉन्फ़िगरेशन तय नहीं किया गया है, तो यह डिफ़ॉल्ट रूप से, मैनेज किए जा रहे नेमस्पेस का स्टेटस, 'Current' को सेट कर देता है.

इस हेडर के मौजूद होने के बाद, कम्पैटबिलटी रैपर हेडर में अब इनमें बदलाव किए जा सकते हैं:

#include 

#if WEAVE_CONFIG_MERCURY_NAMESPACE == kWeaveManagedNamespace_Development
#include 
#else
#include 
#endif // WEAVE_CONFIG_MERCURY_NAMESPACE == kWeaveManagedNamespace_Development

या नाम स्थान मैनेजमेंट के इस्तेमाल के उदाहरण के लिए जो भी सही हो.

डेवलपमेंट कॉन्टेंट बनाएं

इसलिए, अब इन्फ़्रास्ट्रक्चर और नई सुविधाओं के साथ-साथ मौजूदा एपीआई और नई सुविधाओं पर भी काम चल रहा है.

% mkdir Development
% touch Development/Mercury.hpp Development/Bar.hpp Development/Foo.hpp Development/Foobar.hpp
% cat << EOF > Development/MercuryManagedNamespace.hpp
#ifndef _WEAVE_MERCURY_MANAGEDNAMESPACE_DEVELOPMENT_HPP
#define _WEAVE_MERCURY_MANAGEDNAMESPACE_DEVELOPMENT_HPP

#include 

#if defined(WEAVE_CONFIG_MERCURY_NAMESPACE) && WEAVE_CONFIG_MERCURY_NAMESPACE != kWeaveManagedNamespace_Development
#error Compiling Weave Mercury development-designated managed namespace file with WEAVE_CONFIG_MERCURY_NAMESPACE defined != kWeaveManagedNamespace_Development
#endif

#ifndef WEAVE_CONFIG_MERCURY_NAMESPACE
#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Development
#endif

namespace nl {
namespace Weave {
namespace Profiles {

namespace WeaveMakeManagedNamespaceIdentifier(Mercury, kWeaveManagedNamespaceDesignation_Development) { };

namespace Mercury = WeaveMakeManagedNamespaceIdentifier(Mercury, kWeaveManagedNamespaceDesignation_Development);

}; // namespace Profiles
}; // namespace Weave
}; // namespace nl

#endif // _WEAVE_MERCURY_MANAGEDNAMESPACE_DEVELOPMENT_HPP
EOF

बेशक, अगर कोई मॉड्यूल यहां दिए गए उदाहरण से बहुत आसान है और उसमें कई क्लास, सोर्स, फ़ाइलें या हेडर नहीं हैं, तो यह सब एक ही हेडर फ़ाइल में किया जा सकता है. ऐसा करने के लिए, फ़ाइलों को इधर-उधर ले जाना और एक से ज़्यादा स्टैंडअलोन कॉन्फ़िगरेशन और साथ काम करने वाले हेडर बनाए बिना ऐसा किया जा सकता है. हालांकि, इस जटिल उदाहरण की मदद से, इसे मैनेज किए गए नेमस्पेस के समाधान के साथ-साथ मुश्किल से आसान के स्पेक्ट्रम के साथ प्रेरणा मिलना चाहिए.

मैनेज किए जा रहे नेमस्पेस का इस्तेमाल इंटिग्रेटर के तौर पर करना

Weave SDK इंटिग्रेटर का मुख्य फ़ोकस, Weave SDK के सार्वजनिक एपीआई हेडर को शामिल करना और उनके लिए ऐप्लिकेशन डेवलप करना और उन्हें इंटिग्रेट करना है.

काम करने वाले उदाहरण के तौर पर, फिर से एक Weave प्रोफ़ाइल, Mercury की मान लें, जिसमें Next-, करंट-, और लेगसी की ओर से तय किए गए मैनेज किए गए नेमस्पेस हैं, जिनके सार्वजनिक हेडर इस तरह से स्ट्रक्चर किए गए हैं:

  • Weave/Profiles/Mercury/Mercury.hpp
  • Weave/Profiles/Mercury/Bar.hpp
  • Weave/Profiles/Mercury/Foo.hpp
  • Weave/Profiles/Mercury/Foobar.hpp
  • Weave/Profiles/Mercury/Next/Mercury.hpp
  • Weave/Profiles/Mercury/Next/Bar.hpp
  • Weave/Profiles/Mercury/Next/Foo.hpp
  • Weave/Profiles/Mercury/Next/Foobar.hpp
  • Weave/Profiles/Mercury/Current/Mercury.hpp
  • Weave/Profiles/Mercury/Current/Bar.hpp
  • Weave/Profiles/Mercury/Current/Foo.hpp
  • Weave/Profiles/Mercury/Current/Foobar.hpp
  • Weave/Profiles/Mercury/Legacy/Mercury.hpp
  • Weave/Profiles/Mercury/Legacy/Bar.hpp
  • Weave/Profiles/Mercury/Legacy/Foo.hpp
  • Weave/Profiles/Mercury/Legacy/Foobar.hpp

जहां Mercury.hpp "एंब्रेला" हेडर मॉड्यूल है.

जब तक इस्तेमाल का उदाहरण साफ़ तौर पर Weave में मैनेज किए जा रहे नेमस्पेस को शामिल न करने को बढ़ावा न देता हो, उदाहरण के लिए:

#include 

Weave मॉड्यूल सार्वजनिक हेडर को उनके मैनेज नहीं किए जा रहे डिफ़ॉल्ट पाथ से रेफ़रंस देना सबसे अच्छा है (उदाहरण के लिए, Weave/Profiles/Mercury/Mercury.hpp). ऐसा करने से, किसी प्रोजेक्ट में शामिल डायरेक्टिव में लगातार बदलाव किए बिना, एपीआई डेवलप होने के प्रोसेस के प्रोग्रेस को फ़ॉलो किया जा सकता है, क्योंकि वे एपीआई मैनेज की गई lifecycle से होकर गुज़रते हैं.

इस रणनीति के मुताबिक डिप्लॉयमेंट, मैनेज किए जा रहे किसी दूसरे नेमस्पेस के नाम पर अपने कोड को फिर से टारगेट कर सकते हैं. उदाहरण के लिए, C/C++ प्रीप्रोसेसर में मनचाहा कॉन्फ़िगरेशन तय करके. यह कार्रवाई कमांड लाइन, सोर्स कोड में या किसी कॉन्फ़िगरेशन या प्रीफ़िक्स हेडर में की जा सकती है:

#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Current

और मैनेज नहीं किए जा रहे / अमान्य हैं पाथ का इस्तेमाल करें:

#include 

टारगेट किए गए एपीआई के लिए मैनेज किए जा रहे नेमस्पेस के तय समय में बदलाव होने पर, जैसे कि 'मौजूदा' से 'लेगसी' में, सिर्फ़ प्रीप्रोसेसर की परिभाषा को अडजस्ट करके फिर से टारगेट करें:

#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Legacy