Libelektra: प्रकार के लिए पुस्तकालय

मुझे लगता है कि प्रस्तावों के आधार पर पुस्तकालय बनाने का यह असाधारण तरीका होना चाहिए। प्लगइन्स के बीच सामान्य कार्यक्षमता निकालने और उसमें से एक पुस्तकालय बनाने के लिए यह बहुत अधिक समझ में आता है। @ bauhaus93 के TOML प्लगइन में बहुत सारे कोड हैं जो लाइब्रेरी में डालने के लिए बहुत मायने रखते हैं (उदाहरण के लिए कमेंट हैंडलिंग कोड)।

मुझे गलत मत समझो, यह @ bauhaus93 के लिए अच्छा इनपुट है। और अगर कोई दूसरा प्लगइन है जिसे समान कार्यक्षमता की आवश्यकता है, तो हमें निश्चित रूप से इसे एक पुस्तकालय में रखना चाहिए। लेकिन लाइब्रेरी बनाना प्लगइन-विशिष्ट कोड होने की तुलना में बहुत अधिक प्रयास है और प्रयास केवल तभी किया जाना चाहिए जब वास्तव में कम से कम दो ग्राहक हों।

@ bauhaus93 यदि आपको एक प्रकार की लाइब्रेरी (उदाहरण के लिए किसी अन्य प्लगइन के साथ पुन: उपयोग) होने में तत्काल लाभ नहीं दिखता है, तो कृपया समस्या को बंद कर दें।

यदि कोई दूसरा प्लगइन है जिसे समान कार्यक्षमता की आवश्यकता है, तो हमें निश्चित रूप से इसे एक पुस्तकालय में रखना चाहिए

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

इसके अलावा पुस्तकालय होने से वास्तव में किसी को एक नया स्टोरेज प्लगइन लिखने के लिए प्रोत्साहित किया जा सकता है, क्योंकि कुछ काम पहले ही हो चुका है।

लेकिन मैंने इसे low priority रूप में टैग किया, ठीक इसलिए क्योंकि मुझे पता था कि यह बहुत काम है और शायद ऐसा कोई नहीं है जो इसे करना चाहता है।

प्रकारों के लिए, मैं गैर-दशमलव पूर्णांकों (बाइनरी/ऑक्टल/हेक्साडेसिमल) या डेटाटाइम्स के सत्यापन/रूपांतरण को छोड़कर, पुन: प्रयोज्यता के बारे में निश्चित नहीं हूं (टीओएमएल आरएफसी 3339 डेटाटाइम का उपयोग करता है)।
प्रकारों से असंबंधित, मुझे कीसेट टू-बी-लिखने की तैयारी में कुछ पुन: प्रयोज्यता दिखाई देती है (उदाहरण के लिए, फ़ंक्शन जो array मेटाकी को अपडेट/जोड़ते हैं, अमान्य सरणियों के array मेटाकी को हटाते हैं या लापता comment/#X पूरा करते हैं।

आपने अभी तक इस पर ध्यान नहीं दिया होगा, लेकिन बूलियन के सामान्यीकरण में भी समस्याएँ हो सकती हैं जैसे कि प्लगइन करता है। यह संभवत: सबसे अधिक उपयोग किया जाने वाला कोड है, क्योंकि अधिकांश प्रारूप true / false का उपयोग करेंगे लेकिन इलेक्ट्रा 1 / 0 । मुझे लगता है कि yamlcpp को कुछ विशेष कोड जोड़ना पड़ा, ताकि बूलियन को पूर्णांक या इसके विपरीत (या उन पंक्तियों के साथ कुछ) में परिवर्तित नहीं किया जा सके।

आह हाँ, इसके बारे में भूल गए, TOML प्लगइन को भी इन मानों को सामान्य करना है।

समस्या केवल यह नहीं है कि आपको मूल्यों को सामान्य बनाना है। आपको यह भी जानना होगा कि type प्लगइन क्या करता है, क्योंकि यह kdbSet चरण में toml प्लगइन से पहले चलता है। मुझे यकीन नहीं है, अगर हमने कभी इसे लागू किया है, लेकिन आपको यह भी सुनिश्चित करना चाहिए कि type प्लगइन केवल 1 / 0 या true / false kdbSet चरण में, उपयोगकर्ता द्वारा प्रदान किए गए कॉन्फ़िगरेशन की परवाह किए बिना। अन्यथा toml को type प्लगइन कॉन्फ़िगरेशन को पार्स करने में सक्षम होना होगा, क्योंकि उपयोगकर्ता कस्टम सत्य और गलत मान सेट कर सकता है (नीचे परीक्षण केस देखें)

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L734 -L771

दिलचस्प हिस्सा है:

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L749 -L753

type प्लगइन प्राप्त करता है एक 1 में kdbGet (हो सकता है से toml ), लेकिन रिटर्न एक t में kdbSet । यह true = 0 और false = 1 को परिभाषित करने वाले उपयोगकर्ता तक जा सकता है जो toml प्लगइन को पूरी तरह से भ्रमित कर देगा। (मुझे लगता है कि सभी बूलियन प्रत्येक kdbSet पर फ़्लिप करेंगे)

यह बेहद जटिल बातचीत इसलिए है कि मुझे लगता है कि type प्लगइन स्टोरेज प्रारूपों के लिए होना चाहिए जिसमें प्रकार नहीं हैं और जिनके पास है उन्हें type के उपयोग को स्पष्ट रूप से मना करना चाहिए। लेकिन इसे व्यवहार्य बनाने के लिए हमें स्टोरेज प्लगइन्स, यानी टाइप लाइब्रेरी के भीतर प्रकारों का समर्थन करने का एक आसान तरीका चाहिए।

चूंकि toml प्लगइन हेक्साडेसिमल संख्याओं को भी संभालता है, इसलिए संभवतः इसे hexnumber प्लगइन का उपयोग करके स्पष्ट रूप से अस्वीकार करना चाहिए। (हालांकि उस स्थिति में मुझे लगता है कि समस्याओं की संभावना कम है)

इसके अलावा पुस्तकालय होने से वास्तव में किसी को एक नया स्टोरेज प्लगइन लिखने के लिए प्रोत्साहित किया जा सकता है, क्योंकि कुछ काम पहले ही हो चुका है।

अधिकांश उपयोगकर्ता शायद केवल व्याकरण लिखना चाहते हैं और शेष जादुई रूप से अपने आप हो जाना चाहिए। मुझे आश्चर्य है कि कितनी दूर @ bauhaus93 की TOML प्लगइन ने वास्तव में इस लक्ष्य को प्राप्त किया है। TOML प्लगइन के कोड-बेस के साथ एक गैर-TOML प्लगइन बनाना दिलचस्प होगा। हालांकि, अकेले एक प्रकार की लाइब्रेरी मुझे "भंडारण प्लगइन लिखने" के बड़े कार्य के लिए अत्यधिक उपयोगी होने के लिए विशेष रूप से विशिष्ट लगती है।

प्रकारों के लिए, मैं गैर-दशमलव पूर्णांकों (बाइनरी/ऑक्टल/हेक्साडेसिमल) या डेटाटाइम्स के सत्यापन/रूपांतरण को छोड़कर, पुन: प्रयोज्यता के बारे में निश्चित नहीं हूं (टीओएमएल आरएफसी 3339 डेटाटाइम का उपयोग करता है)।

दिनांक/समय केवल सत्यापन के लिए इलेक्ट्रा में मौजूद था लेकिन वहां केवल RFC2822 समर्थित था। दिनांक प्लगइन RFC 3339 को मान्य करने के लिए आपके पार्सर का पुन: उपयोग कर सकता है लेकिन मैं इसे बहुत कम प्राथमिकता मानूंगा।

एक (टीओएमएल) तिथि वाली कुंजी से keyGetDateTime(Key *k, struct tm *tm) जैसा कुछ और रोमांचक होगा।

प्रकारों से असंबंधित, मुझे कीसेट टू-बी-लिखने की तैयारी में कुछ पुन: प्रयोज्यता दिखाई देती है (उदाहरण के लिए फ़ंक्शन जो सरणी मेटाकी को अपडेट/जोड़ते हैं, अमान्य सरणी के सरणी मेटाकी को हटाते हैं या लापता टिप्पणी/# एक्स मेटाकी डेटा को पूरा करते हैं)।

हाँ, यह दिलचस्प हो सकता है। लेकिन इससे भी अधिक आकर्षक यह होगा कि जितना संभव हो सके व्याकरण और स्पर्श कोड को सीधे संशोधित करने की संभावना: पलक:

आपने अभी तक इस पर ध्यान नहीं दिया होगा, लेकिन बूलियन के सामान्यीकरण में भी समस्याएँ हो सकती हैं जैसे कि प्लगइन करता है।

जो गायब है वह है doc/tutorials/storage-plugins.md में कुछ ट्यूटोरियल/स्पष्टीकरण जो एक अप-टू-डेट दृश्य देता है कि एक स्टोरेज प्लगइन को वास्तव में किन प्लगइन्स पर भरोसा करना चाहिए। #2330 दिखाएगा कि क्या "बाइनरी" की आवश्यकता हो सकती है और अभी भी डिफ़ॉल्ट भंडारण के रूप में उपयुक्त है।

आपको यह भी जानना होगा कि टाइप प्लगइन क्या करता है, क्योंकि यह kdbSet चरण में toml प्लगइन से पहले चलता है।

शायद, स्टोरेज प्लगइन्स को टाइप प्लगइन का उपयोग करना बंद कर देना चाहिए और बस अपना सामान्यीकरण स्वयं करना चाहिए (उनके प्रारूप में जो कुछ भी सच/गलत है, उससे इलेक्ट्रा में 1/0 और इसी तरह)। @ bauhaus93 आप किस प्रकार के प्लगइन की अन्य कार्यक्षमता का उपयोग करते हैं?

यह एक उपयोगकर्ता के रूप में जा सकता है जो कि true = 0 और false = 1 को परिभाषित करता है जो पूरी तरह से toml प्लगइन को भ्रमित करेगा।

मैं टाइप प्लगइन की कार्यक्षमता को कम करने के पक्ष में हूं। यदि कुछ भी हो, तो कुछ अतिरिक्त सही/गलत मान उपयोगकर्ता द्वारा परिभाषित किए जाने चाहिए (जो स्पष्ट रूप से पहले सत्य/गलत मान नहीं थे)।

चूंकि toml प्लगइन हेक्साडेसिमल संख्याओं को भी संभालता है, इसलिए संभवतः इसे हेक्सनंबर प्लगइन का उपयोग करके स्पष्ट रूप से अस्वीकार करना चाहिए। (हालांकि उस स्थिति में मुझे लगता है कि समस्याओं की संभावना कम है)

यह व्यक्त करने का कोई तरीका नहीं है कि प्लगइन्स एक साथ काम नहीं करते हैं (ऐसी कार्यक्षमता होने से माउंटिंग और अधिक जटिल हो जाएगी। हमारे लिए यह तालिका बनाए रखना भी बहुत अधिक काम होगा कि कौन सा प्लगइन किस प्लगइन के साथ काम करता है।) लेकिन शायद किसी के पास उन्हें एक साथ उपयोग करने का विचार नहीं होगा, क्योंकि TOML प्लगइन में पहले से ही यह कार्यक्षमता और बहुत कुछ है (जैसे बाइनरी नंबर भी)।

अधिकांश उपयोगकर्ता शायद केवल व्याकरण लिखना चाहते हैं और शेष जादुई रूप से अपने आप हो जाना चाहिए।

यह संभव होने के लिए थोड़ा जादुई लगता है। यह एक संशोधित Yacc या ANTLR व्याकरण के आधार पर एक कस्टम कोड जनरेटर के साथ संभव हो सकता है। लेकिन मुझे नहीं लगता कि कोड रखने का कोई तरीका है जो JSON, XML, TOML और edn जैसे व्यापक रूप से भिन्न प्रारूपों के लिए व्याकरण से KeySet s बनाता है। जैसा कि @'sanssecours ने पाया कि YAML जैसे प्रारूप भी हैं जिन्हें मानक व्याकरण प्रारूप में व्यक्त करना बहुत कठिन है।

हालांकि, अकेले एक प्रकार की लाइब्रेरी मुझे "भंडारण प्लगइन लिखने" के बड़े कार्य के लिए अत्यधिक उपयोगी होने के लिए विशेष रूप से विशिष्ट लगती है।

हम निश्चित रूप से पुस्तकालय को एक सामान्य storage पुस्तकालय में विस्तारित कर सकते हैं जो भंडारण प्लगइन्स के लिए अधिक सहायक कार्य प्रदान करता है (उदाहरण के लिए stdin / stdout और आयात/निर्यात के लिए पाइप)। टाइप स्टफ तब उसी का हिस्सा होगा।

मुझे यह भी लगता है कि आप इस बात को कम आंकते हैं कि सामान कितना जटिल हो सकता है। यदि हमारे पास एक मानक प्रकार की लाइब्रेरी होती, तो टाइप सिस्टम का विस्तार करना भी आसान होता, उदाहरण के लिए पूर्णांकों के पूर्व-पार्स किए गए बाइनरी संस्करणों को स्टोर करना (स्ट्रिंग संस्करणों को पार्सिंग ओवरहेड को कम करने के लिए)। एक storage पुस्तकालय आंतरिक एपीआई (यदि आवश्यक हो) का भी उपयोग कर सकता है, क्योंकि यह एलेक्ट्रा डेवलपर्स द्वारा बनाए रखा जाता है।

एक अन्य मानक प्रकार की लाइब्रेरी भी प्रकार की समस्याओं के लिए मानक त्रुटि संदेशों की गारंटी देगी। तो अंत उपयोगकर्ताओं के लिए भी एक फायदा होगा।

कुछ और अधिक रोमांचक क्या होगा जैसे keyGetDateTime(Key *k, struct tm *tm)

libease ( elektraKeyToDateTime (const Key * key, struct tm * dateTime) ) के रूपांतरण भाग के लिए नौकरी की तरह लगता है।

@ bauhaus93 वहां के कार्य toml लिए भी उपयोगी हो सकते हैं। वे इस तरह से डिज़ाइन किए गए हैं जैसे elektraKeyToFloat और elektraFloatToString पूरी तरह से और दोषरहित राउंडट्रिप (चाहे आप एक स्ट्रिंग के फ्लोट से शुरू करें) और उनका उपयोग उच्च स्तरीय एपीआई में भी किया जाता है। तो अगर toml साथ कुंजी बनाता है elektra*ToString यह निश्चित रूप से उच्च स्तरीय एपीआई द्वारा सही ढंग से पढ़ा जा सकता है और toml निश्चित रूप से सही ढंग से पढ़ सकता है जो भी highlevel एपीआई के साथ उत्पादित elektraKeyTo* ।

एक अप-टू-डेट दृश्य, जिस पर एक स्टोरेज प्लग इन वास्तव में निर्भर होना चाहिए।

IMO, एक स्टोरेज प्लगइन को कभी भी किसी अन्य प्लगइन पर _rely_ नहीं होना चाहिए। स्टोरेज प्लगइन्स को अन्य प्लगइन्स द्वारा बढ़ाया जा सकता है, लेकिन उन्हें आदर्श रूप से स्टैंडअलोन काम करना चाहिए।

यहां तक ​​​​कि बाइनरी कुंजियों से निपटने के लिए, स्टोरेज/टाइप लाइब्रेरी द्वारा बेहतर हल किया जाएगा। फिर से यह त्रुटि संदेशों आदि के लिए कुछ आधारभूत मानक की गारंटी देता है। यह उन प्रारूपों के लिए binary प्लगइन के उपयोग से भी बचता है जिनकी आवश्यकता नहीं है। जबकि binary उदाहरण के साथ संयुक्त रूप से quickdump काम करेगा, यह गति और भंडारण आकार दोनों के लिए खराब है।

शायद, स्टोरेज प्लगइन्स को टाइप प्लगइन का उपयोग करना बंद कर देना चाहिए और बस अपना सामान्यीकरण करना चाहिए

इसलिए मैंने एक पुस्तकालय का प्रस्ताव रखा। एक पुस्तकालय प्रदान करना बेहतर है जो प्लगइन को क्या करना है इसका अनौपचारिक विवरण (या यहां तक ​​​​कि औपचारिक विनिर्देश) देने के बजाय काम करता है। विशेष रूप से, यदि विनिर्देश समय के साथ बदल सकता है।

मैं टाइप प्लगइन की कार्यक्षमता को कम करने के पक्ष में हूं।

पहले से लागू की गई कार्यक्षमता को क्यों हटा दें? मूल रूप से, विचार एक अलग boolean प्लगइन रखने का था, लेकिन इससे प्लगइन ऑर्डरिंग और ऐसी चीजों के कारण भी समस्याएं हुईं।

यदि कुछ भी हो, तो कुछ अतिरिक्त सही/गलत मान उपयोगकर्ता द्वारा परिभाषित किए जाने चाहिए (जो स्पष्ट रूप से पहले सत्य/गलत मान नहीं थे)।

इसकी वास्तव में कोई आवश्यकता नहीं है। केवल एक समस्या है, यदि एक से अधिक प्लगइन परिभाषित करता है कि बूलियन मान क्या है।

यहां तक ​​कि true = 0 और false = 1 भी पूरी तरह से ठीक हैं। इलेक्ट्रा स्वयं बूलियन्स पर जुर्माना लगाता है क्योंकि " 1 एकमात्र सही मूल्य है और 0 एकमात्र गलत मूल्य है"।

यह व्यक्त करने का कोई तरीका नहीं है कि प्लगइन्स एक साथ काम नहीं करते हैं (ऐसी कार्यक्षमता होने से माउंटिंग और अधिक जटिल हो जाएगी। हमारे लिए यह तालिका बनाए रखना भी बहुत अधिक काम होगा कि कौन सा प्लगइन किस प्लगइन के साथ काम करता है।)

मैं असहमत हूं। एक विस्तृत सूची निश्चित रूप से असंभव होगी (आखिरकार तीसरे पक्ष के प्लगइन्स भी हैं), लेकिन समाधान सरल है। प्लगइन्स को स्वयं जांच करने दें। या तो elektra<Plugin>Get या किसी अन्य फ़ंक्शन में जिसे kdb mount दौरान कहा जाता है।

बूलियन के अलावा, TOML प्लगइन पढ़ने पर स्ट्रिंग, डबल और (unsigned_)long_long प्रकार भी सेट करता है।

मैं @kodebach से सहमत type प्लगइन का उपयोग केवल प्लग-इन द्वारा किया जाना चाहिए, जिसमें अंतर्निर्मित प्रकार की प्रणाली नहीं है, क्योंकि बातचीत में कठिनाइयों का सामना करना पड़ता है।
उदा. TOML प्लगइन गैर-दशमलव मानों पर भी पढ़ने पर पूर्णांकों के लिए type मेटाकी सेट करता है (इसे दशमलव में परिवर्तित करते समय, गैर-दशमलव प्रतिनिधित्व को origvalue में संग्रहीत करता है)। हालाँकि, यदि आप kdb set साथ इस तरह के टाइप किए गए मान को बदलना चाहते हैं (और बाइनरी/ऑक्टल/हेक्स मान द्वारा ऐसा करते हैं) तो आप सीधे ऐसा नहीं कर सकते (कुंजी मान सेट करके), क्योंकि type प्लगइन प्रकार की जांच सफल नहीं होगी। आपको इसके बजाय origvalue मेटाकी को बदलना होगा। (नया मान सेट करने से पहले type मेटाकी को हटाना काम नहीं करेगा, क्योंकि मेटाकी को पढ़ने पर फिर से सेट किया जाएगा।)

समस्या केवल यह नहीं है कि आपको मूल्यों को सामान्य बनाना है। आपको यह भी जानना होगा कि टाइप प्लगइन क्या करता है, क्योंकि यह kdbSet चरण में toml प्लगइन से पहले चलता है। मुझे यकीन नहीं है, अगर हमने कभी इसे लागू किया है, लेकिन आपको यह भी सुनिश्चित करना चाहिए कि टाइप प्लगइन केवल kdbSet चरण में 1/0 या सही/गलत उत्पन्न करता है, उपयोगकर्ता द्वारा प्रदान किए गए कॉन्फ़िगरेशन के बावजूद। अन्यथा toml को टाइप प्लगइन कॉन्फ़िगरेशन को पार्स करने में सक्षम होना होगा, क्योंकि उपयोगकर्ता कस्टम सत्य और गलत मान सेट कर सकता है (नीचे परीक्षण केस देखें)

हाँ, मैं पहले से ही सोच रहा था, अगर मैं वास्तव में उपयोगकर्ता परिभाषित बूलियन मानों की जांच कर सकता हूं। वर्तमान में, लिखने पर, TOML प्लगइन केवल "1" और "true" मानों को सत्य मानता है, बाकी को असत्य के रूप में देखा जाएगा।

@kodebach ने लिखा:

यह संभव होने के लिए थोड़ा जादुई लगता है।

ऑगियस के साथ यह संभव है (लेकिन आपको जो पेड़ मिलते हैं वे इतने वांछनीय नहीं हैं)। यह दिलचस्प होगा कि हम मौजूदा टीओएमएल समाधान से कितनी दूर हैं। बेशक आपको कुछ एमिटर कोड लिखने की जरूरत है लेकिन यह आमतौर पर इतना नाटकीय नहीं होता है।

जेएसओएन, एक्सएमएल

इलेक्ट्रा का यह लाभ है कि विभिन्न तकनीकों में इस तरह के व्यापक रूप से भिन्न स्वरूपों को लागू किया जा सकता है। एक्सएमएल को खरोंच से लागू करने की कोशिश करना शायद सबसे अच्छा विचार नहीं है। यदि आईएनआई जैसे प्रारूपों को कवर किया जा सकता है, तो यह पहले से ही आश्चर्यजनक होगा।

लेकिन निश्चित रूप से पहली और सबसे महत्वपूर्ण बात एक अच्छा TOML प्लगइन प्राप्त करना है: 1st_place_medal:

एक अन्य मानक प्रकार की लाइब्रेरी भी प्रकार की समस्याओं के लिए मानक त्रुटि संदेशों की गारंटी देगी।

अन्य प्लगइन्स में जांच आसानी से की जा सकती है (#2963 हो जाने के बाद)। यदि कोई प्लगइन केवल एक सुंदर त्रुटि संदेश के साथ जाँच और विफल करता है, तो बहुत कम / कोई इंटरैक्शन नहीं होता है।

मुक्ति के रूपांतरण भाग के लिए नौकरी की तरह लगता है

हां, शायद TOML की कुछ चीजें लिबेज या लिबमेटा में जा सकती हैं।

आईएमओ, एक स्टोरेज प्लगइन को कभी भी किसी अन्य प्लगइन पर भरोसा नहीं करना चाहिए।

बाइनरी के लिए मुझे अभी तक यकीन नहीं है (जैसा कि शायद ऐसा कुछ है जो डिफ़ॉल्ट बैकएंड के लिए जरूरी नहीं है), अन्य सभी कार्यक्षमताओं के लिए, यह भी मेरा निष्कर्ष है। हालांकि इस निष्कर्ष को अभी व्यापक रूप से स्वीकार नहीं किया गया है (@sanssecours?)

इसलिए मैंने एक पुस्तकालय का प्रस्ताव रखा। एक पुस्तकालय प्रदान करना बेहतर है जो प्लगइन को क्या करना है इसका अनौपचारिक विवरण (या यहां तक ​​​​कि औपचारिक विनिर्देश) देने के बजाय काम करता है। विशेष रूप से, यदि विनिर्देश समय के साथ बदल सकता है।

यह निर्भर करता है: यदि बड़ी संख्या में वैध संभावनाएं हैं, तो एक जटिल पुस्तकालय से एक ट्यूटोरियल/विवरण बेहतर हो सकता है जो किसी भी तरह से यह लचीलापन देने की कोशिश करता है। और क्रमांकन के लिए वैध संभावनाओं की एक विशाल श्रृंखला है और उनमें से कई में जटिल कार्यान्वयन तक (जैसे कि कुछ मापदंडों के साथ elektraFormat को कॉल करना) तुच्छ कार्यान्वयन हैं (उदाहरण के लिए यदि वे कई सुविधा अभ्यावेदन का समर्थन करते हैं)।

पहले से लागू की गई कार्यक्षमता को क्यों हटा दें?

इलेक्ट्रा वर्तमान में बहुत अधिक कोड बनाए रखने के भार पर गिर रहा है। हर बेकार (इस अर्थ में कि कोई भी इसका उपयोग नहीं करता है) कोड की लाइन जिससे हम छुटकारा पाते हैं, इलेक्ट्रा को बेहतर बनाती है।

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

हम वह सब कुछ जारी नहीं कर सकते जो हमारे पास वर्तमान में 1.0 के रूप में है, तब इलेक्ट्रा एक निराशा होगी। हमें हर उस चीज से छुटकारा पाने की जरूरत है जिसकी जरूरत नहीं है। हम आपके द्वारा की जा सकने वाली हर सफाई की सराहना करते हैं।

यही कारण है कि TOML INI की जगह लेगा। #3491

प्लगइन्स को स्वयं जांच करने दें।

यह शायद ही कभी एक अच्छा समाधान था। यह बहुत असंगत हो जाता है और प्लगइन्स जोड़ने का क्रम अलग-अलग परिणाम दे सकता है। क्या ऐसा कोड पहले से कहीं मौजूद है?

@ बौहौस93 ने लिखा:

बूलियन के अलावा, TOML प्लगइन पढ़ने पर स्ट्रिंग, डबल और (unsigned_)long_long प्रकार भी सेट करता है।

लेकिन यह सब बिना टाइप प्लगइन के अपने आप ही करता है? प्लगइन किस प्रकार के लिए उपयोग किया जाता है?

आपको इसके बजाय मूल मूल्य मेटाकी को बदलना होगा।

हाँ, यहाँ हमारे पास अभी तक कोई अच्छा समाधान नहीं है (#3056)। keySetString मूल को हटा देता है लेकिन किसी तरह व्यवहार अभी भी वैसा नहीं है जैसा उपयोगकर्ता अपेक्षा करता है।

वर्तमान में, लिखने पर, TOML प्लगइन केवल "1" और "सत्य" के मानों को सत्य मानता है, शेष को असत्य के रूप में देखा जाएगा।

शायद हमें अधिक सख्त होना चाहिए और "0" या "1" नहीं हर चीज पर असफल होना चाहिए। TOML फ़ाइल में ही आप केवल "सत्य" और "गलत" की अनुमति देते हैं और कुछ नहीं?

लेकिन यह सब बिना टाइप प्लगइन के अपने आप ही करता है? प्लगइन किस प्रकार के लिए उपयोग किया जाता है?

हाँ, यह अपने आप करता है, लेक्सिंग के दौरान विभिन्न प्रकारों का मिलान हो जाएगा। हालांकि, यह जांच नहीं करता है कि दशमलव/डबल मान ओवर-/अंडरफ्लो long_long / double , इसलिए मुझे लगता है कि यह type प्लगइन द्वारा किया जाता है।

शायद हमें अधिक सख्त होना चाहिए और "0" या "1" नहीं हर चीज पर असफल होना चाहिए। TOML फ़ाइल में ही आप केवल "सत्य" और "गलत" की अनुमति देते हैं और कुछ नहीं?

हां, मैं इसे और सख्त बना सकता हूं। फ़ाइल में केवल true या false बूलियन के रूप में लिखा/पढ़ा जाता है।

अन्य सभी कार्यक्षमताओं के लिए, यह भी मेरा निष्कर्ष है।

उस स्थिति में हमें type लाइब्रेरी की आवश्यकता होती है। अन्यथा प्रकार के प्रारूप के लिए किसी भी स्टोरेज प्लगइन ने प्रकार की सामग्री को फिर से कार्यान्वित किया होगा (चूंकि किसी अन्य प्लगइन पर भरोसा करना सवाल से बाहर है)।

यदि बड़ी संख्या में वैध संभावनाएं हैं, तो एक ट्यूटोरियल/विवरण बेहतर हो सकता है

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

क्या ऐसा कोड पहले से कहीं मौजूद है?

AFAIK यह मुझे यकीन नहीं है कि एक प्लगइन यह पता लगा सकता है कि कौन से अन्य प्लगइन्स आरोहित हैं।

लेकिन यह सब बिना टाइप प्लगइन के अपने आप ही करता है? प्लगइन किस प्रकार के लिए उपयोग किया जाता है?

हाँ, यह अपने आप करता है, लेक्सिंग के दौरान विभिन्न प्रकारों का मिलान हो जाएगा। हालांकि, यह जांच नहीं करता है कि दशमलव/डबल मान ओवर-/अंडरफ्लो long_long / double , इसलिए मुझे लगता है कि यह type प्लगइन द्वारा किया जाता है।

हाँ type रेंज जाँच भी करता है, float / double और कुछ अन्य सामान जैसे enum s को मान्य करता है।

शायद हमें अधिक सख्त होना चाहिए और "0" या "1" नहीं हर चीज पर असफल होना चाहिए। TOML फ़ाइल में ही आप केवल "सत्य" और "गलत" की अनुमति देते हैं और कुछ नहीं?

और यह प्रकार या अधिक विशेष रूप से रूपांतरण/सामान्यीकरण के लिए इन बेहद जटिल और जटिल मामलों में से एक है।

चलो मान लेते हैं toml केवल स्वीकार करता है true / false इनपुट के रूप में और केवल पैदा करता है 0 / 1 में kdbGet और यह केवल स्वीकार करता है 0 / 1 और केवल पैदा करता है true / false में kdbSet । यह बूलियन के लिए इलेक्ट्रा स्पेक और टीओएमएल स्पेक दोनों का अनुपालन करेगा। लेकिन एक उपयोगकर्ता शायद उम्मीद करेगा कि kdb set /some/key/mounted/with/toml true काम करेगा। हालाँकि, ऐसा नहीं होता है। type लिए सही कॉन्फ़िगरेशन के साथ यह काम कर सकता है, लेकिन यह जल्दी से अजीब हो जाता है। उदाहरण के लिए, क्या होगा यदि कुंजी पहले मौजूद थी। फिर कोई type मेटाकी नहीं है और type प्लगइन बस इसे अनदेखा करता है, toml true प्राप्त करता है और शिकायत करता है कि true मान्य नहीं है बूलियन...

यह सिर्फ यह दर्शाता है कि एक स्टोरेज प्लगइन को किसी भी अन्य प्लगइन्स का उपयोग किए बिना स्टोरेज प्रारूप का समर्थन करने वाले सभी प्रकार और संबंधित रूपांतरणों को संभालने में सक्षम होना चाहिए।

इलेक्ट्रा वर्तमान में बहुत अधिक कोड बनाए रखने के भार पर गिर रहा है। हर बेकार (इस अर्थ में कि कोई भी इसका उपयोग नहीं करता है) कोड की लाइन जिससे हम छुटकारा पाते हैं, इलेक्ट्रा को बेहतर बनाती है।

यह एक उचित बिंदु है, हालांकि मुझे नहीं लगता कि केवल कोड हटाना सही समाधान है। कम से कम जब प्लगइन्स की बात आती है तो नहीं। मूल रूप से, मैं सहमत हूं, कम एलओसी बेहतर है। प्लगइन्स के लिए, हम आसानी से कह सकते हैं कि प्लगइन या उसका कुछ हिस्सा प्रयोगात्मक है।

आईएमओ, एक स्टोरेज प्लगइन को कभी भी किसी अन्य प्लगइन पर भरोसा नहीं करना चाहिए।

हालांकि इस निष्कर्ष को अभी व्यापक रूप से स्वीकार नहीं किया गया है (@sanssecours?)

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

मैं यह भी नहीं सोचता कि चिंताओं को अलग करने के दृष्टिकोण से यह बहुत अच्छा है। मेरी राय में एक अच्छा स्टोरेज प्लगइन लिखना पहले से ही काफी काम है।

वह सहायक पुस्तकालय की बात है। यह सामान्य कोड को विभाजित करता है और इस प्रकार (कुछ) चिंताओं को अलग करने के साथ-साथ प्लगइन के विकास को आसान बनाता है।

@markus2330 की चिंता के बारे में कि एक सामान्य प्रयोजन पुस्तकालय विकसित करना एक समान प्लगइन की तुलना में कठिन है: यह तथ्यात्मक रूप से गलत है, क्योंकि आप पुस्तकालय के रूप में वर्तमान elektraTypeGet फ़ंक्शन का थोड़ा संशोधित संस्करण प्रदान कर सकते हैं। संशोधनों की आवश्यकता केवल इसलिए है क्योंकि हमें Plugin * handle को KeySet * config से बदलने की आवश्यकता है। हालांकि यह सभी समस्याओं का समाधान नहीं कर सकता है, यह कम से कम स्टोरेज प्लगइन को यह नियंत्रित करने देता है कि प्रकार की सामग्री कैसे और कब की जाती है।

उदाहरण के तौर पर, toml में एक आईएनआई फ़ॉलबैक मोड हो सकता है जहां यह टीओएमएल प्रकार प्रणाली का उपयोग नहीं करता है बल्कि इसके बजाय type और एक सामान्य टीओएमएल मोड को स्थगित कर देता है जहां यह elektraTypeGet प्रदान करता है एक बहुत ही सटीक विन्यास के साथ जो सुनिश्चित करता है कि सब कुछ TOML युक्ति के अनुरूप हो।

संक्षेप में, एक पुस्तकालय भंडारण प्लगइन के दृष्टिकोण से एक प्लगइन की तुलना में बहुत अधिक लचीला है। कम से कम वर्तमान प्लगइन कॉन्फ़िगरेशन संभावनाओं के साथ।

यह आवश्यक है कि एक स्टोरेज प्लगइन प्रकार रूपांतरण, निर्देशिका कुंजी और बाइनरी डेटा (बेस 64 एन्कोडिंग) का ख्याल रखता है, उस काम को आसान नहीं बनाता है।

आइए इसे तोड़ दें:

• बाइनरी डेटा: वास्तव में ऐसा कुछ करने में कोई प्रयास शामिल नहीं है:
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  एक अलग प्लगइन भी काम करेगा, जब तक स्टोरेज प्लगइन यह लागू कर सकता है कि अन्य प्लगइन सभी परिस्थितियों में आरोहित है और यह मान सकता है कि कोई बाइनरी कुंजी नहीं है। यदि प्लगइन को अभी भी keyIsBinary पर कॉल करना है और एक त्रुटि फेंकना है, तो इस समाधान के लिए शून्य लाभ है। मुझे यह भी पसंद नहीं है कि एक अलग बाइनरी प्लगइन को एक ही बार में पूरे KeySet को कनवर्ट करना होगा, क्योंकि तब सभी बेस 64 कुंजियां काफी मेमोरी बर्बाद कर देती हैं।
• निर्देशिका कुंजियाँ: सबसे पहले मूल्यों वाली ये गैर-पत्ती कुंजियाँ लगभग सभी परिस्थितियों में अजीब हैं और हमें वास्तव में अनुशंसा करनी चाहिए कि इनसे बचा जाए। जब इन चाबियों से निपटने की बात आती है, जैसा कि #3256 में कहा गया है, मुझे लगता है कि इस मामले के लिए एक पुस्तकालय बेहतर अनुकूल है। मेमोरी और प्रोसेसिंग ओवरहेड, अनावश्यक रूप से जटिल माउंटपॉइंट कॉन्फ़िगरेशन और लचीलेपन सहित कई कारण हैं। ऐसा लगता है @markus2330 (कुछ हद तक) इस बिंदु पर मुझसे सहमत हैं।
• प्रकार: किसी प्रारूप के लिए कोई भी स्टोरेज प्लगइन जिसमें मूल प्रकार का सिस्टम है, उसे प्रकारों के लिए कम से कम कुछ काम करना होगा। यह कुछ लाइब्रेरी को कॉल करके किसी अन्य प्लगइन को कॉन्फ़िगर करने के लिए स्क्रैच से पूर्ण रूपांतरण करने से लेकर हो सकता है। हर चीज के लिए सिर्फ काम करना कभी भी संभव

हालांकि, यह जांच नहीं करता है कि दशमलव/डबल मान अधिक-/अंडरफ्लो long_long/डबल है, इसलिए मुझे लगता है कि टाइपप्लगिन द्वारा किया जाता है।

ठीक है, तो आप मूल रूप से इसे केवल जाँच के लिए उपयोग करते हैं।

लेकिन उस स्थिति में एक अलग प्लगइन भी समाधान नहीं है

नहीं, दुर्भाग्य से अलग प्लगइन्स समाधान नहीं हैं। हम वहां असफल रहे। वर्तमान समाधान यह है कि प्रत्येक स्टोरेज प्लगइन doc/tutorials/storage-plugins.md के आधार पर सब कुछ (बाइनरी हैंडलिंग को छोड़कर) लागू करता है।

लेकिन एक उपयोगकर्ता शायद यह उम्मीद करेगा कि kdb set /some/key/mounted/with/toml true काम करेगा।

नहीं, उपयोगकर्ता को इसकी अपेक्षा नहीं करनी चाहिए। इलेक्ट्रा में 1/0 सही/गलत हैं। केवल स्टोरेज प्लगइन्स ही इसे किसी और चीज़ से मैप कर सकते हैं।

तर्क: जैसा कि कम से कम विनिर्देश स्तर पर केवल 1/0 काम कर रहे हैं, यह केवल कहीं और सही/गलत काम करने के लिए भ्रमित करने वाला होगा (भंडारण प्लगइन्स के अपवाद के साथ)।

यह सिर्फ यह दर्शाता है कि एक स्टोरेज प्लगइन को किसी भी अन्य प्लगइन्स का उपयोग किए बिना स्टोरेज प्रारूप का समर्थन करने वाले सभी प्रकार और संबंधित रूपांतरणों को संभालने में सक्षम होना चाहिए।

हाँ मैं सहमत हूँ।

यह एक उचित बिंदु है, हालांकि मुझे नहीं लगता कि केवल कोड हटाना सही समाधान है।

बेशक हमें "सही" कोड को हटाने की जरूरत है: वह जो आपको इसे पूरा किए बिना या इलेक्ट्रा के अन्य भागों के साथ समस्याओं को पेश किए बिना उम्मीदें देता है। और टाइप प्लगइन की कुछ कार्यक्षमता इलेक्ट्रा के अन्य हिस्सों के साथ मिलकर समस्याएं पैदा करती है।

कम से कम जब प्लगइन्स की बात आती है तो नहीं। मूल रूप से, मैं सहमत हूं, कम एलओसी बेहतर है। प्लगइन्स के लिए, हम आसानी से कह सकते हैं कि प्लगइन या उसका कुछ हिस्सा प्रयोगात्मक है।

दुर्भाग्य से, यह काम नहीं करता (अभी तक *)। लोग प्लगइन्स की स्थिति को सही ढंग से नहीं आंकते हैं, उदाहरण के लिए हाल ही में देखें: #3472 जहां अनियमित और बग-रहित आईएनआई प्लगइन, और इससे भी बदतर, निराश विरासती xmltool प्लगइन, पूरी तरह से काम करने के लिए माना जाता था।

• यह बेहतर काम कर सकता है अगर मैं #666 पर फिर से काम करता हूं और हम माउंटिंग के दौरान चेतावनियां आउटपुट करते हैं।

यह आवश्यक है कि एक स्टोरेज प्लगइन प्रकार रूपांतरण, निर्देशिका कुंजी और बाइनरी डेटा (बेस 64 एन्कोडिंग) का ख्याल रखता है, उस काम को आसान नहीं बनाता है।

@sanssecours YAML प्लगइन्स प्रकार रूपांतरण को कैसे संभालते हैं?

यह तथ्यात्मक रूप से गलत है

हम देखेंगे कि यह कब किया जाता है :stuck_out_tongue_winking_eye:

संक्षेप में, एक पुस्तकालय भंडारण प्लगइन के दृष्टिकोण से एक प्लगइन की तुलना में बहुत अधिक लचीला है। कम से कम वर्तमान प्लगइन कॉन्फ़िगरेशन संभावनाओं के साथ।

इस पर किसी ने बहस नहीं की। लेकिन लचीलापन कभी-कभी बड़ी कीमत के साथ आता है।

कुछ ऐसा करने में वास्तव में कोई प्रयास शामिल नहीं है

बेस 64 बाइनरी डेटा को एन्कोड करने का एकमात्र तरीका नहीं है। मानकों के लिए जहां बेस 64 की आवश्यकता है, इसे हार्ड-कोड किया जा सकता है। ( @sanssecours क्या यह

टीओएमएल के लिए हालांकि, यह बस "बेस 64 या कोई अन्य उपयुक्त एएससीआईआई या यूटीएफ -8 एन्कोडिंग" कहता है, इसलिए अन्य बाइनरी प्लगइन्स का उपयोग किया जा सकता है। इसलिए वर्तमान समाधान के फायदे हैं, क्योंकि उपयोगकर्ता अन्य बाइनरी प्लगइन्स को आवश्यकतानुसार या आवश्यकतानुसार माउंट कर सकते हैं।

@ bauhaus93 - infos/needs = base64 को - infos/needs = binary बदला जाना चाहिए।

सबसे पहले मूल्यों के साथ ये गैर-पत्ती कुंजी लगभग सभी परिस्थितियों में अजीब हैं और हमें वास्तव में अनुशंसा करनी चाहिए कि इन्हें टाला जाए।

कई प्रारूपों में बहुत आम हैं। और जब आप एक विनिर्देश का विस्तार करते हैं तो वे बहुत उपयोगी हो सकते हैं (उन कुंजियों से उपकुंजियां बनाएं जिनमें मान थे)।

[निर्देशिका कुंजी] ऐसा लगता है कि @ मार्कस 2330 (कुछ हद तक) इस बिंदु पर मुझसे सहमत हैं।

मैं स्टोरेज प्लगइन्स पर सहमत हूं कि इसे संभालने की जरूरत है (शायद लाइब्रेरी के साथ लेकिन "डायरेक्टरीवैल्यू" प्लगइन के साथ नहीं क्योंकि एस्केपिंग काम नहीं करता है और सही एस्केपिंग स्टोरेज प्लगइन की मुख्य नौकरियों में से एक है)।

ठीक है, तो आप मूल रूप से इसे केवल जाँच के लिए उपयोग करते हैं।

मैं " toml प्लगइन type प्लगइन का उपयोग करता है" वाक्यांश से असहमत हूं। वर्तमान संस्करण में यह केवल type अनुशंसा करता है।

https://github.com/ElektraInitiative/libelektra/blob/c61e388c4aa950cf84aa2f00fba7cdd34a47640e/src/plugins/toml/README.md#L5 -L6

भले ही type को needs रूप में घोषित किया गया हो, मैं इसे "उपयोग" नहीं कहूंगा। toml वास्तव में type पर कोई सीधा नियंत्रण नहीं है। इसलिए मैंने कहा कि toml type पर निर्भर करता है। यह उम्मीद करता है कि type कुछ चीजें एक निश्चित तरीके से करें, लेकिन अगर ऐसा नहीं है तो मैं कुछ नहीं कर सकता।

यह बेहतर काम कर सकता है अगर मैं #666 पर फिर से काम करता हूं और हम माउंटिंग के दौरान चेतावनियां आउटपुट करते हैं।

मैं सहमत हूँ। शायद हर kdbGet भी, जब तक कि एक विशेष "मैं स्वीकार करता हूं कि यह माउंटपॉइंट प्रयोगात्मक प्लगइन्स का उपयोग करता है" कुंजी सेट नहीं की गई है।

बेस 64 बाइनरी डेटा को एन्कोड करने का एकमात्र तरीका नहीं है।

यह वास्तव में binary प्लगइन के लिए एक तर्क है। हालांकि मुझे अभी भी एक इंटरफ़ेस चाहिए जिसके माध्यम से प्लगइन एक समय में एक ही कुंजी काम कर सकता है, यह कुछ मेमोरी बचत और शायद प्रदर्शन बचत भी प्राप्त कर सकता है। (लेकिन यह एक और मुद्दा है)

कई प्रारूपों में बहुत आम हैं।

आपके पास कोई उदाहरण है?

और जब आप एक विनिर्देश का विस्तार करते हैं तो वे बहुत उपयोगी हो सकते हैं (उन कुंजियों से उपकुंजियां बनाएं जिनमें मान थे)।

सच है, लेकिन उस स्थिति में मैं "या तो-या" समाधान (अंतिम उपयोगकर्ता पीओवी से) की अनुशंसा करता हूं। या तो आप एकल मान के साथ पुरानी कुंजी का उपयोग करते हैं, या आप उपकुंजियों के साथ नए संस्करण का उपयोग करते हैं। अन्यथा विन्यास शायद भ्रमित करने वाला होगा।

स्पष्ट होने के लिए, मुझे नहीं लगता कि मूल्यों के साथ गैर-पत्ती कुंजियों का कभी भी उपयोग नहीं किया जाना चाहिए, लेकिन यदि संभव हो तो उन्हें टाला जाना चाहिए और शायद ही कभी (यदि कभी हो) पसंदीदा समाधान हैं।

लेकिन "directoryvalue" प्लगइन के साथ नहीं, क्योंकि भागने से काम नहीं चलता है

#3256 में मैंने बचने की समस्याओं को हल करने के लिए मेटाडेटा के उपयोग का सुझाव दिया। इसके अलावा #3223 से मेरे विचार हैं जो बचने की समस्या को हल करेंगे (प्रत्येक उपयोग-मामले के लिए न केवल directoryvalue ) साथ ही साथ कुछ अन्य चीजें भी। (बहुत औपचारिक) प्रस्ताव भी देखें। मैं उस दस्तावेज़ में आज या कल सादे अंग्रेजी स्पष्टीकरण जोड़ूंगा, क्योंकि मैं अभी भी इन परिवर्तनों के पक्ष में हूं।

@sanssecours YAML प्लगइन्स प्रकार रूपांतरण को कैसे संभालते हैं?

यान एलआर और वाईएएमएल सीपीपी बूलियन के लिए type प्लगइन का उपयोग करते हैं। वाईएएमएल सीपीपी बाइनरी डेटा के लिए base64 प्लगइन का भी उपयोग करता है।

बेस 64 बाइनरी डेटा को एन्कोड करने का एकमात्र तरीका नहीं है। मानकों के लिए जहां बेस 64 की आवश्यकता है, इसे हार्ड-कोड किया जा सकता है। ( @sanssecours क्या यह

हां, जहां तक ​​​​मुझे पता है कि वाईएएमएल में बाइनरी डेटा हमेशा बेस 64 एन्कोडिंग का उपयोग करता है।

[मूल्यों के साथ गैर-पत्ती कुंजी] क्या आपके पास एक उदाहरण है?

XML और अधिकांश INI बोलियाँ (क्योंकि [key] मौजूद होने पर भी वे key=value अनुमति देती हैं)

सच है, लेकिन उस स्थिति में मैं "या तो-या" समाधान (अंतिम उपयोगकर्ता पीओवी से) की अनुशंसा करता हूं। या तो आप एकल मान के साथ पुरानी कुंजी का उपयोग करते हैं, या आप उपकुंजियों के साथ नए संस्करण का उपयोग करते हैं। अन्यथा विन्यास शायद भ्रमित करने वाला होगा।

हाँ, यह उचित लगता है। एक बार जब आप जान जाते हैं कि कुछ एक खंड है, तो आप आमतौर पर मूल्य को अनुभाग के भीतर कहीं ले जाते हैं।

जैसे deluser.conf में BACKUP = 0 और BACKUP_TO = "." । अनुभागों के साथ, अधिकांश एप्लिकेशन केवल BACKUP बजाय BACKUP_ENABLE उपयोग करेंगे।

इसके अलावा #3223 से मेरे विचार हैं जो बचने की समस्या को हल करेंगे (प्रत्येक उपयोग-मामले के लिए न केवल directoryvalue ) साथ ही साथ कुछ अन्य चीजें भी।

मैंने अब प्रस्ताव को #3223 में अपडेट कर दिया है। मुझे आशा है कि अब इसे समझना आसान हो गया है (यह अभी भी बहुत लंबा है)।

https://github.com/kodebach/libelektra/blob/dcec6e865bba32f6d83c40c2f711c2e70dde6d62/doc/proposals/keynames.md

बड़ा सवाल यह है कि यह सब कौन लागू करेगा। यह यथास्थिति से काफी दूर है, यानी, बहुत सारा काम (अकेले शब्दावली में बदलाव एक बड़ी मात्रा में काम है)। यदि आप इसे लागू करना चाहते हैं, तो आप प्रस्ताव के साथ एक पीआर बना सकते हैं और मैं इस पर टिप्पणी करता हूं। अन्यथा, हमें एक कदम पीछे हटना चाहिए और अपनी पहुंच के भीतर व्यवहार्य समाधानों के बारे में सोचना चाहिए।

बीटीडब्ल्यू। प्रस्ताव का पहला भाग वास्तव में एक अद्भुत ट्यूटोरियल है कि प्रमुख नाम कैसे काम करते हैं। इसे ट्यूटोरियल के रूप में रखना आश्चर्यजनक होगा। :स्पार्कलिंग_हार्ट:

बड़ा सवाल यह है कि यह सब कौन लागू करेगा।

हमेशा यही सवाल...

यह यथास्थिति से काफी दूर है, यानी, बहुत सारा काम (अकेले शब्दावली में बदलाव एक बड़ी मात्रा में काम है)।

शब्दावली में परिवर्तन निश्चित रूप से सबसे बड़ा हिस्सा है, विशेष रूप से सभी दस्तावेज़ीकरण को बदलना। हालाँकि, यह एक व्यक्ति द्वारा नहीं किया जाना चाहिए। ये परिवर्तन काफी सरल हैं, वे केवल थकाऊ हैं, इसलिए कोड के बारे में व्यापक ज्ञान के बिना भी कोई भी मदद कर सकता है। अधिकांश भाग के लिए यह सभी दस्तावेजों को पढ़ने और "आधार नाम" जैसी चीजों की घटनाओं को बदलने के बराबर है।

यदि आप इसे लागू करना चाहते हैं, तो आप प्रस्ताव के साथ एक पीआर बना सकते हैं और मैं इस पर टिप्पणी करता हूं। अन्यथा, हमें एक कदम पीछे हटना चाहिए और अपनी पहुंच के भीतर व्यवहार्य समाधानों के बारे में सोचना चाहिए।

मैं एक पीआर शुरू करूंगा, लेकिन क्या मेरे पास इसे (अकेले) खत्म करने का समय है, मैं नहीं कह सकता।
मेरे पास पहले से ही एक स्थानीय शाखा है जिसमें सभी कॉल keyBaseName , keySetBaseName और keyAddBaseName को keyLastUnescapedPart , keySetLastUnescapedPart / keySetLastLiteralPart और keyAddUnescapedPart / keyAddLiteralPart । मैंने पहला प्रस्ताव लिखने के बाद अर्ध-स्वचालित रेगेक्स-प्रतिस्थापन का उपयोग करके बनाया है।

लेकिन उस शाखा में पुराने कार्यों के लिए नए कार्य सिर्फ #define s हैं, इसलिए वास्तविक कार्यान्वयन अभी भी लिखा जाना है और फिर परीक्षण और शायद भंडारण प्लगइन्स को अद्यतन करना होगा।

मेरे लिए सबसे बड़ी समस्या स्टोरेज प्लगइन्स होगी। मैं कोर और परीक्षणों और शायद एक स्टोरेज प्लगइन के अपडेट को कार्यान्वित कर सकता हूं। लेकिन मैं पसंद करूंगा, अगर मुझे सभी स्टोरेज प्लगइन्स के लिए कोड का अध्ययन नहीं करना है और सभी प्रारूपों की सभी पेचीदगियों का पता लगाना है।

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

इसलिए मैंने इसे इस तरह लिखा है। मेरी योजना #3447 में दस्तावेज़ीकरण के लिए इस प्रस्ताव के कुछ हिस्सों का पुन: उपयोग करने की थी। मैं इसे 1:1 का उपयोग नहीं कर सकता क्योंकि मैंने कुछ बहुत महत्वपूर्ण भागों को छोड़ दिया है (उदाहरण के लिए विहित बनाम गैर-विहित)।

मुझे साफ-साफ बोलने की जरूरत है और आपको कोई गलत उम्मीद नहीं देनी चाहिए: जैसा कि आपने LCDproc में देखा, ऐसा नहीं होता है कि अन्य लोग कार्यों को पूरा करने के लिए आगे बढ़ रहे हैं, खासकर तब नहीं जब वे थकाऊ हों। एक पीआर जो एक को छोड़कर सभी स्टोरेज प्लगइन्स को नष्ट कर देता है, वह अविभाज्य है। और स्टोरेज प्लगइन्स को इस पीआर से अधिक लाभ नहीं मिलता है, वास्तव में वे इस अर्थ में "बदतर" हो जाते हैं कि वे अचानक फाइलों पर सिंटैक्स त्रुटियां उत्पन्न करेंगे जिन्हें वे अभी पार्स कर सकते हैं। इसका मतलब यह नहीं है कि यह कुल मिलाकर एक बुरा विचार है। कुछ सुधारों के साथ यह यथास्थिति से बेहतर हो सकता है, लेकिन मैं यह नहीं देखता कि हम इतने बड़े काम को कैसे कर सकते हैं और इतने सारे अन्य जरूरी महत्वपूर्ण खुले कार्यों के साथ जो अभी हमारे पास हैं।

तो कृपया हमें #3447 (दस्तावेज़) पर ध्यान दें, अंत में #2969 को पूरा करना, TOML प्लगइन में सुधार करना और 1.0 के लिए आवश्यक अन्य महत्वपूर्ण विषय (https://github.com/ElektraInitiative/libelektra/milestone/12 और https://) github.com/ElektraInitiative/libelektra/milestone/14)। एक बार यह अच्छा लगने पर, हम देख सकते हैं कि हम और कौन से विचार प्राप्त कर सकते हैं।

मेरे लिए इस चर्चा का निष्कर्ष यह है कि निश्चित रूप से पुस्तकालयों को स्टोरेज प्लगइन्स लिखना आसान बनाने की आवश्यकता है क्योंकि प्लगइन-दृष्टिकोण काम नहीं करता है (बाइनरी को छोड़कर देखा जाना है)। यह निष्कर्ष स्टोरेज प्लगइन ट्यूटोरियल में होना चाहिए।
@ bauhaus93 क्या आप स्टोरेज प्लगइन ट्यूटोरियल जारी रखने के लिए कार्य कर सकते हैं? अब आपके पास बहुत सारी अंतर्दृष्टि है, जिसे toml प्लगइन के स्रोत कोड को देखकर नहीं देखा जा सकता है।

एक पीआर जो एक को छोड़कर सभी स्टोरेज प्लगइन्स को नष्ट कर देता है, वह अविभाज्य है।

मुझे उम्मीद नहीं थी कि कोई इस तरह के पीआर को मर्ज करेगा... मैंने अभी कहा कि यह अच्छा होगा यदि अन्य लोग स्टोरेज प्लगइन्स के अपडेट में मदद कर सकें। आदर्श रूप से प्लगइन के मूल लेखक। #3491 के बाद कुछ अधिक जटिल स्टोरेज प्लग इन को वैसे भी हटा दिया जाएगा, जिससे पूरा कार्य आसान हो जाएगा।

और स्टोरेज प्लगइन्स को इस पीआर से अधिक लाभ नहीं मिलता है, वास्तव में वे इस अर्थ में "बदतर" हो जाते हैं कि वे अचानक फाइलों पर सिंटैक्स त्रुटियां उत्पन्न करेंगे जिन्हें वे अभी पार्स कर सकते हैं।

यह मामला नहीं हो सकता। प्रस्ताव के अंत में आंशिक स्पष्टीकरण भी है। AFAIK ऐसा कोई मामला नहीं होना चाहिए, जहां एक स्टोरेज प्लगइन को फ़ाइल देना चाहिए , क्योंकि इसका अनुवाद KeySet में नहीं किया जा सकता है।

एक अपवाद प्रारूप होगा, जो सीधे इलेक्ट्रा के कुंजी नामों का उपयोग करता है (बच निकला या बच नहीं गया)। ये इस प्रस्ताव के बाद पहले की तुलना में कम फ़ाइलें स्वीकार कर सकते हैं। लेकिन चूंकि इन फाइलों के लिए सिंटैक्स हमेशा कुंजी नामों के सिंटैक्स पर निर्भर करता है, यह पूरी तरह से अपेक्षित है।

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

मैंने कभी नहीं सोचा था कि इस प्रस्ताव को तुरंत स्वीकार कर लिया जाएगा। लेकिन मुझे लगता है कि हमें 1.0 से पहले इसे लागू करने पर जरूर विचार करना चाहिए। 1.0 जारी होने के बाद प्रस्ताव एक बड़ा ब्रेकिंग बदलाव होगा। मुझे नहीं लगता कि 1.0 के 1 या 2 साल बाद भी 2.0 संस्करण जारी करना (उससे पहले कोई बात नहीं) एलेक्ट्रा के लक्षित दर्शकों को देखते हुए एक अच्छा विचार होगा।

तो कृपया हमें #3447 (दस्तावेज़) पर ध्यान दें, अंत में #2969 को पूरा करना, TOML प्लगइन में सुधार करना और 1.0 के लिए आवश्यक अन्य महत्वपूर्ण विषय

मैं पूरी तरह सहमत हूँ। लेकिन फिर से, हमें अभी भी इस पर विचार करना चाहिए, क्योंकि 1.0 जारी होने के बाद, ब्रेकिंग परिवर्तन जोड़ना काफी समय के लिए बहुत कठिन होगा।

मेरे लिए इस चर्चा का निष्कर्ष यह है कि निश्चित रूप से पुस्तकालयों को स्टोरेज प्लगइन्स लिखना आसान बनाने की आवश्यकता है

मैं

बाइनरी को छोड़कर देखा जाना है

आईएमओ, बाइनरी वैल्यू का मामला बहुत अलग है। यह कई अन्य ( rgbcolor , macaddr , ipaddr , आदि) की तरह एक 1:1 महत्वपूर्ण मूल्य अनुवाद है, इसलिए एक प्लगइन वास्तव में यहां उपयुक्त है। हालाँकि, जैसा कि मैंने कहा, एक नया प्लगइन एपीआई जो समय पर सिर्फ एक कुंजी से संबंधित है, एक सुधार हो सकता है। लेकिन इसे 1.0 के बाद आसानी से जोड़ा जा सकता है क्योंकि अगर इसे सही तरीके से किया जाए तो यह एक ब्रेकिंग बदलाव नहीं होगा।

सबसे -> चाहिए?

हां, मैं इसे उसी तरह देखता हूं: यह अवास्तविक है कि 1.0 के बाहर होने के बाद यह परिवर्तन होगा (1.0 का पूरा उद्देश्य ऐसे निर्णयों को रोकना है ताकि अन्य लोग इस पर भरोसा कर सकें) और इससे पहले इस तरह के सुधार करना अच्छा होगा . लेकिन जैसा कि कहा गया है: हमें वास्तव में महत्वपूर्ण चीजों को पूरा करने पर ध्यान केंद्रित करने की जरूरत है और अच्छी-से-अच्छी लड़ाइयों में अपनी ऊर्जा नहीं खोनी चाहिए, हम अपनी वर्तमान जनशक्ति के साथ नहीं जीत सकते।