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

खास जानकारी

परिचय

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

पद

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

• डेवलपमेंट
• आगे बढ़ें
• मौजूदा
• लेगसी

डेवलेपमेंट

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

अगला

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

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

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

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

मौजूदा

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

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

विरासती

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

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

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

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

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

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

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

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

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

अगर किसी मौजूदा कोड की जगह नया कोड लागू करना है, लेकिन कुछ रिलीज़ साइकल तक ऐसे कोड को बनाए रखना ज़रूरी है, तो इस फ़ील्ड को 'लेगसी' पर माइग्रेट कर दिया जाता है.

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

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

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

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

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

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

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

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/MercuryManagedNamespace.hpp. एक से ज़्यादा हेडर फ़ाइलें होने पर, हर हेडर फ़ाइल में इस तरह का हेडर बनाना बेहतर होता है. साथ ही, इस कॉन्टेंट को बार-बार बनाएं और उसका डुप्लीकेट बनाएं.

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

#include <Weave/Support/ManagedNamespace.hpp>

#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 <Weave/Support/ManagedNamespace.hpp>

#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

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

यह हेडर मिलने के बाद, कंपैटबिलिटी रैपर हेडर में बदलाव करके, इसमें ये चीज़ें शामिल की जा सकती हैं:

#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 <Weave/Support/ManagedNamespace.hpp>

#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 सार्वजनिक API हेडर को शामिल करना और उनके लिए ऐप्लिकेशन को इंटिग्रेट करना और डेवलप करना.

काम करने वाले उदाहरण के तौर पर, हम फिर से 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.hpp). ऐसा करने से, प्रोजेक्ट के डायरेक्टिव में लगातार बदलाव किए बिना एपीआई डेवलपमेंट की प्रोग्रेस को फ़ॉलो किया जा सकता है, क्योंकि वे एपीआई, मैनेज की गई लाइफ़साइकल से भेजे जाते हैं.

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

#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Current

और मैनेज नहीं किए गए / बिना शर्तें वाले पाथ का इस्तेमाल करें:

#include 

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

#define WEAVE_CONFIG_MERCURY_NAMESPACE kWeaveManagedNamespace_Legacy