Libelektra: الأحرف المحجوزة في Key Names

راجع أيضًا # 2698 للمناقشة حول الحرف الذي سيتم استخدامه للمصفوفة (globbing)

بادئ ذي بدء ، إذا قمت بإدراج \ ، فيجب عليك أيضًا وضع / في القائمة. من الواضح أن الشرطة المائلة هي الحرف المحجوز النموذجي (حرف ذو معنى خاص) في Elektra.

ثانيًا ، لا تعد عبارة "used for globbing" و "تستخدم للإشارة إلى parentKey ، على سبيل المثال في البرنامج المساعد الشرطي" حالات استخدام صالحة هنا. هذه ليست معاني خاصة أثناء عدم الهروب. إذا كنت ترغب في منع تفسير خاص يحدث لاحقًا (على سبيل المثال عن طريق مكون إضافي أو مكتبة) ، فعليك إما أن تعرف أن هذا التفسير يعتمد على اسم المفتاح الذي تم تجاوزه (والذي سيكون سيئًا ، كما هو موضح في https: // github. com / ElektraInitiative / libelektra / issues / 2698 # issuecomment-554636250) ، أو عليك التأكد من عدم إمكانية تفسير الاسم الذي لم يتم إلغاءه بشكل خاص.

لنأخذ # كمثال. تفسر مكتبتنا المتلألئة اسم المفتاح /a/# أنه يعني "تطابق أي عنصر مصفوفة في المصفوفة /a ". إذا كنا لا نريد ذلك ، لكننا نريد مطابقة /a/# حرفياً ، فنحن بحاجة إلى استخدام نوع من الهروب. ومع ذلك ، لا يعمل /a/\# . ما الذي تحققه الشرطة المائلة للخلف أثناء إلغاء الهروب من اسم المفتاح؟ لمنع التفسير الخاص للمكتبة المتلألئة ، يجب أن تبقى هناك أثناء عدم الهروب. لكن هذا ينتهك القاعدة (°) التي تقضي بضرورة إفلات الشرطة المائلة العكسية ، إذا لم تكن شخصية هروب بحد ذاتها (فهي ليست شخصية هروب ، إذا لم تختفي أثناء إلغاء الهروب). لذلك نحتاج إلى استخدام /a/\\# ، والذي لن يتم تجاوزه إلى ⊙a⊙\# (بدلاً من NUL ، تم حذف مساحة الاسم والنهاية). ولكن في هذه الحالة ، فإن # ليس له معنى خاص لاسم المفتاح الذي لا مفر منه ولا يجب أخذه في الاعتبار على الإطلاق.

بعبارة أخرى ، لإعطاء سبب لضرورة هروب شخصية ما (سبب حجزها) ، عليك التفكير في _ "ما هو سلوك elektraKeyNameCanonicalize أو elektraKeyNameUnescape يمنع الهروب؟" _ .

بالنسبة إلى الشخصيات التي نريد فعلاً "حجزها" ، هناك قرار يتعين علينا اتخاذه هنا. هل هذه _الأحرف لها معنى خاص_ أم أحرف محجوزة فعلية؟

في رأيي ، _الأحرف ذات المعنى الخاص_ هي أحرف عادية يمكن استخدامها على هذا النحو ، ولكن قد يكون لها تفسير خاص في سياق معين (على سبيل المثال % إذا كان هو الجزء الرئيسي بالكامل).

_الأحرف المحجوزة_ من ناحية أخرى محجوزة لسياقات خاصة. لا يمكن استخدامها بشكل طبيعي ولا يُسمح بها إلا في السياقات الخاصة ، حيث يكون لها معنى خاص.

الحرف ذو المعنى الخاص لا يجب تجاوزه إلا في السياق الذي يكون فيه تفسيره الخاص ، إذا كان هذا التفسير الخاص غير مرغوب فيه. خارج هذا السياق ، قد يُسمح بالهروب أو يُمنع ، اعتمادًا على موقفنا من الهروب غير الضروري (° °).

من ناحية أخرى ، يجب تخطي الحرف المحجوز متى لم يكن له معنى خاص. هذا يعني أنه في السياق الذي يكون فيه له معنى خاصًا ، يمكن الهروب منه لتجنب المعنى الخاص. خارج هذا السياق ، يجب الهروب منه.

كمثال ، دعنا ننظر إلى % . إذا كان جزء المفتاح بالكامل هو % (على سبيل المثال ، /%/ ) ، فإن هذا الجزء غير مهرب إلى جزء فارغ. في كلتا الحالتين ، ستمنع الشرطة المائلة للخلف في /\%/ التفسير الخاص ولن يتم تجاوزها إلى جزء % . يصبح الاختلاف ملحوظًا ، مع ذلك ، إذا نظرنا إلى سياقات مختلفة ، مثل /a%b/ .

إذا تعاملنا مع % أنه _حرف _ محجوز_ ، فإن /a%b/ هو اسم / جزء مفتاح غير قانوني ويجب أن نخطئ. الطريقة الصحيحة لتحقيق الجزء الذي لم يتم تجاوزه a%b بحرف _ محجوز_ ستكون باستخدام /a\%b/ .

إذا رأينا % كشخصية ذات معنى خاص_ ، فإن /a%b/ سيكون صحيحًا و unescape إلى a%b . مرة أخرى ، ما إذا كان مسموحًا أيضًا بـ /a\%b/ يعتمد على موقفنا من الهروب غير الضروري. إذا كان مسموحًا به ، فإنه يتحول أيضًا إلى a%b .

ملاحظة: بالنسبة لـ / لا يوجد قرار ، كلا التفسيرين متكافئين ، حيث لا يوجد سياق ، حيث / ليس له معنى خاص. بالنسبة إلى \ قررنا بالفعل (في # 3115) معاملته على أنه _حرف محجوز_ وبالتالي يتطلب الهروب ، عندما لا يتم استخدامه كحرف هروب نفسه.

يتطلب القرار أعلاه بالطبع أيضًا تحديد السياقات التي يمكن أن يكون فيها لهذه الشخصيات ، الآن أو في المستقبل ، معاني خاصة.

يوجد حلان سهلان هنا:
تعامل مع كل شيء (باستثناء / و \ ) على أنها _أحرف ذات معنى خاص_ ، واسمح للهروب غير الضروري ، وبالنسبة للأشياء غير المستخدمة ، حدد أن لها تفسيرًا خاصًا في جميع السياقات. التفسير الخاص لهذه الأشياء هو أنها تجعل اسم المفتاح غير قانوني. لذلك يجب دائمًا الهروب غير المستخدمة. يمكن دائمًا تخطي أي قائمة أحرف أخرى ، ولكن يجب أن يتم ذلك فقط ، إذا أردنا منع تفسير خاص معين.

-

(°) كما هو مذكور في # 3115 ، فإن هذه القاعدة تجعل فهم النظام بأكمله أسهل كثيرًا. في اسم مفتاح مهرب (صالح) ، يهرب الخط المائل العكسي دائمًا من شيء ما. في اسم مفتاح غير مهذب (صالح) ، تكون الشرطة المائلة للخلف دائمًا حرفياً شرطة مائلة للخلف.

(° °) إذا تبنينا موقفًا صارمًا للغاية بشأن الهروب غير الضروري ، فيجب أن يكون من الممكن الحصول على علاقة 1: 1 بين أسماء المفاتيح التي تم تجاوزها والتي لم يتم تجاوزها. هذا بالطبع يتطلب مزيدًا من الجهد في التحقق من صحة أسماء المفاتيح وبالتالي سيكون له تأثير على الأداء (يجب اختبار ما إذا كان هذا التأثير مهمًا بأي شكل من الأشكال).

بادئ ذي بدء ، إذا أدرجت \ ، فيجب عليك أيضًا وضع / في القائمة. من الواضح أن الشرطة المائلة هي الحرف المحجوز النموذجي (حرف ذو معنى خاص) في Elektra.

شكرا لك أضفته. إذا وجدت المزيد من الشخصيات ، فيمكنك ببساطة إضافتها إلى المنشور العلوي.

ثانيًا ، لا تعد عبارة "used for globbing" و "تستخدم للإشارة إلى parentKey ، على سبيل المثال في البرنامج المساعد الشرطي" حالات استخدام صالحة هنا. هذه ليست معاني خاصة أثناء عدم الهروب.

نعم ، بالطبع يمكننا أيضًا استخدام حرف هروب آخر أو حرفين \ لبعض هذه الأحرف. لكن هذا سيكون أكثر تعقيدًا بالنسبة للمستخدمين؟

ما الذي تحققه الشرطة المائلة للخلف أثناء إلغاء الهروب من اسم المفتاح؟

كان يدور في ذهني أن keyAddBaseName (المفتاح "_") سيضيف بالفعل \_ . لذا للحصول على _ (بمعنى الحرف المتلألئ) ، ستحتاج إلى استخدام keyAddName.

على سبيل المثال ، تستخدمsanssecours حاليًا _ داخل أسماء المفاتيح للمكوِّن الإضافي directoryvalue. بالطبع لا توجد طريقة للهروب من هذا ، لأن مثل هذه المحركات الهاربة ليست سهلة الكتابة. كان لدي أمل في أن يكون لدينا مكان واحد لتنفيذ مثل هذا الهروب.

بالنسبة إلى الشخصيات التي نريد فعلاً "حجزها" ، هناك قرار يتعين علينا اتخاذه هنا. هل هذه الشخصيات لها معنى خاص أم أحرف محجوزة فعلية؟

إذا لم يكن لديهم معنى خاص الآن ، فسيتم حجزهم حتى نتمكن من منحهم معنى خاصًا لاحقًا. لا يمكننا "الحجز" أو "إعطاء معنى خاص" في وقت لاحق ، حيث قد تستخدم التطبيقات هذه الأحرف بالفعل.

لتوضيح الأمر: في المنشور العلوي ، "المعنى الخاص" و "المحجوز" مرادفان لمحرك الهروب. وسأحتفظ بها كمرادفات لتسهيل الهروب.

من ناحية أخرى ، يتم حجز الأحرف المحجوزة لسياقات خاصة. لا يمكن استخدامها بشكل طبيعي ولا يُسمح بها إلا في السياقات الخاصة ، حيث يكون لها معنى خاص.

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

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

إذا رأينا٪ كحرف ذي معنى خاص ، فسيكون / a٪ b / صحيحًا وسيُلغى إلى a٪ b.
مرة أخرى ، ما إذا كان / a٪ b / مسموحًا به أيضًا ، يعتمد على موقفنا من الهروب غير الضروري. إذا كان مسموحًا به ، فإنه يتخطى أيضًا إلى٪ b.

بالضبط. لا يمكن للمحرك أن يمنع بشكل كامل من إنشاء أسماء بمعاني خاطئة. لذلك أعتقد أننا لا يجب أن نحاول القيام بذلك. على سبيل المثال ، تحتاج النسبة المئوية في العناصر النائبة إلى عدد زوجي من التكرارات ولكن هناك استثناءات. وربما تضيف بعض الامتدادات للقيم السياقية المزيد من الاستثناءات.

إذا تبنينا موقفًا صارمًا للغاية بشأن الهروب غير الضروري ، فيجب أن يكون من الممكن الحصول على علاقة 1: 1 بين أسماء المفاتيح التي تم تجاوزها والتي لم يتم تجاوزها. هذا بالطبع يتطلب مزيدًا من الجهد في التحقق من صحة أسماء المفاتيح وبالتالي سيكون له تأثير على الأداء (يجب اختبار ما إذا كان هذا التأثير مهمًا بأي شكل من الأشكال).

أعتقد أن أهم هدف يجب أن يكون أن الهروب سهل الفهم والاستخدام. حاول الهروب السابق جاهداً أن يكون كل اسم صالحًا. تسبب مثل هذه الأهداف في الغالب صداعًا ولكنها في الواقع لا تحسن قابلية الاستخدام. إذا وضع شخص ما / في أماكن عشوائية ، فلا بأس من رفض بعض الأسماء. ولكن أمام الأحرف الخاصة ، يجب أن يكون \ دائمًا صالحًا وأن يزيل أي معنى خاص (مستقبلي).

كان يدور في ذهني أن keyAddBaseName (المفتاح "_") سيضيف بالفعل \_ . لذا للحصول على _ (بمعنى الحرف المتلألئ) ، ستحتاج إلى استخدام keyAddName.

هذا محير للغاية بالنسبة لي ...

دلالات keyAddBaseName (Key * key, const char * x) هي:
x جزء لا مفر منه. ستتم إضافته مباشرة إلى نهاية key->ukey . ستتم إضافة شكله المهرب إلى نهاية key->key .

دلالات keyAddName (Key * key, const char * x) هي:
x هو لاحقة اسم هرب (أي صفر أو أكثر أجزاء، لا مساحة الاسم). سيتم تحويله إلى عنوان أساسي وإضافته إلى نهاية key->key . ستتم إضافة النموذج الذي لم يتم إلغاؤه إلى نهاية key->ukey .

الآن ، تريد keyAddBaseName (key, "_") لإضافة الجزء \_ إلى الاسم الذي تم حذفه ، والجزء _ إلى الاسم الذي لم يتم إلغاءه. وهذا لا ينبغي أن يكون له أي تأثير على الخفقان. لكن من المفترض أن يكون لـ keyAddName (key, "_") معنى للتسلل ، فماذا تفعل؟ لا يمكن الهروب من _ بأي شكل من الأشكال ، إنه مجرد حرف واحد. لذلك يتعين علينا إضافة _ لكل من الاسم الذي تم تجاوزه والذي لم يتم تجاوزه. ولكن بعد ذلك ينتج كلا الإصدارين نفس الاسم الذي لم يتم تجاوزه ، مما يعني أنه يجب أن يكون لهما نفس المعنى للتلألؤ ...

يستخدم حاليًا بالفعل _ داخل أسماء المفاتيح للمكوِّن الإضافي directoryvalue.

يستخدم AFAIK directoryvalue الجزء الأساسي فقط /__directoryvalue/ . هذا لا يتعارض بأي حال من الأحوال مع استخدام globbing /_/ .

لا يمكننا "الحجز" أو "إعطاء معنى خاص" في وقت لاحق ، حيث قد تستخدم التطبيقات هذه الأحرف بالفعل.

سيكون مجرد تغيير كبير ، مثل التغيير الذي نقوم به على الأسماء الرئيسية الآن.

أعتقد أننا بحاجة إلى التمييز بين شيئين:

1. الأحرف التي لها معنى خاص لـ keySetName (أو بشكل أكثر تحديدًا elektraKeyNameCanonicalize و elektraKeyNameUnescape ).
2. الأحرف التي لها معنى خاص لمكوِّن إضافي أو مكتبة أو أي جزء آخر من Elektra لا تهتم بمعالجة اسم المفتاح.

ستكون المجموعة الأولى عبارة عن شكل من أشكال الأحرف المحجوزة ، وسيؤدي الاستخدام غير السليم لها إلى فشل keySetName (و keyNew سيعود NULL ). هذا هو المكان الذي يساعد فيه الهروب باستخدام الشرطة المائلة للخلف ، حيث تخبر الشرطة المائلة العكسية keySetName أن تأخذ الحرف التالي حرفيًا وتتجاهل أي معنى قد يحمله.

المجموعة الثانية مختلفة تمامًا. لا يوجد شيء يمكننا القيام به خلال keySetName (أو keyAddName ، keyAddBaseName ، إلخ.) لتغيير ما إذا كان حرف من هذه المجموعة له معنى خاص لبعض المكونات الإضافية أم لا. الأمر متروك تمامًا للإضافة لتقرير ذلك وأي شكل من أشكال الهروب من المكون الإضافي قد يسمح بمنع المعنى الخاص يجب أن يصل إلى المكون الإضافي. ضع في اعتبارك أننا قلنا أن keySetName فشل و keyNew يُرجع NULL للأسماء غير الصالحة. في keySetName
لا يمكننا على سبيل المثال أن نقول أن /# له معنى خاص ، و /#a غير مسموح به ، لكن /\# ليس له معنى خاص /\#a مسموح به. ليس لدينا فكرة ، كيف سيتم استخدام هذا. إذا لم نسمح ببعض المفاتيح ، فلن يتمكن أي مكون إضافي من استخدامها. (ملاحظة: في الفقرة أعلاه: plugin = plugin، library، application، إلخ.)

إذا كنت تريد حقًا التوحيد عندما يكون لشيء ما معنى خاص لمكوِّن إضافي / مكتبة ، يمكنني فقط رؤية شيء مثل هذا يعمل:

حدد بعض قواعد الإفلات لـ % و . و / و \ ، حيث أن التأثير keySetName . قم بعمل عناصر فهرس الصفيف من # 2698. يجب أن تكون أجزاء اسم المفتاح (التي تم تجاوزها والتي لم يتم إلغاؤها) التي تبدأ بـ @ بالشكل (regex) @[^@]+@.+ . قد لا يظهر الحرف @ في أي سياق آخر. كل شيء آخر ليس له معنى خاص خلال keySetName ويمكن استخدامه بدون قيود. قد لا تنسب المكونات الإضافية والمكتبات وما إلى ذلك معنى خاصًا لأي حرف فردي أو جزء من اسم المفتاح باستثناء أجزاء اسم المفتاح التي لم يتم إلغاؤها والتي تبدأ بـ @ . يمكن أن يكون لجزء اسم مفتاح غير مُلغى من النموذج (regex) @[^@]+@.+ معنى خاصًا فقط للمكوِّن الإضافي المسمى بالجزء [^@] من التعبير العادي. ما يعنيه هذا ، يعود إلى الملحق ويحدده الجزء بعد @ .

أدرك أن هذا يختلف تمامًا عن النهج الحالي وغير معقول تمامًا للتنفيذ ، إذا أردنا إصدار 1.0 في أي وقت قريب ، ولكنه نهج العمل الوحيد الذي يمكنني رؤيته ، والذي يسمح لنا أن نقول بشكل قاطع ما إذا كان جزء رئيسي به أي معنى خاص أم لا.

أعتقد أننا بحاجة إلى التمييز بين شيئين:

كان أملي أن نتمكن من تجاهل هذا التمييز لنجعل الهروب بأكمله أسهل في الفهم. ثم لا يضيف keyAddBaseName شيئًا له معنى إلى Elektra.

إذا لم يكن ذلك ممكنًا ، فإن الحد الأدنى من المتطلبات هو أنه من الممكن تمرير أي سلسلة إلى keyAddBaseName واستعادة نفس السلسلة عند طلب الاسم الأساسي باستخدام keyBaseName ، راجع # 2698.

نعم ، سيؤدي ذلك إلى كسر بعض تكرارات keyAddBaseName حيث تمت إضافة أسماء المصفوفات. لكنه سيؤدي إلى كسر بعض الحالات على أي حال ، نظرًا لأن اسم المصفوفة ليس صالحًا الآن ، لذلك نحتاج إلى كسر بعض التعليمات البرمجية أيضًا:

1. يمكن تعيين الكود الذي يفترض أن كل سلسلة أو
2. يمكن إضافة الكود الذي يفترض وجود المصفوفات.

من الواضح جدًا بالنسبة لي أنه لا يجب كسر 1. ، أي الكود الذي يفترض أن كل سلسلة يمكن تمريرها إلى keyAddBaseName . "2" ليست مهمة جدًا ، فهذه بعض التكرارات التي يمكن إصلاحها.

مثال آخر بجانب SSID: يمكن أن تحتوي إدخالات fstab بشكل أساسي على كل شيء بما في ذلك /. أو أسماء mountpoint داخل Elektra.

ثم لا يضيف keyAddBaseName شيئًا له معنى إلى Elektra.

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

المشكلة بالتحديد هي عبارة "المعنى لـ Elektra". يمكننا أن نضمن أن keyAddBaseName لا يضيف أبدًا شيئًا له معنى لـ elektra-core ، أو بعبارات أكثر وضوحًا ، أن keyAddBaseName يضيف وسيطته كجزء من اسم مفتاح جديد لم يتم تجاوزه. ولكن بالنسبة لتطبيق "Elektra" يعني أيضًا أي مكون إضافي لـ Elektra. في هذا التفسير ، يصبح من الصعب جدًا منع keyAddBaseName من إضافة شيء "له معنى". يمكن لأي مكون إضافي أن يقرر أن ينسب المعنى إلى أي اسم مفتاح لم يتم تجاوزه في أي وقت. كما قلت ، الحل الوحيد هو تقديم نظام مقيد للغاية ، مثل ذلك الذي اقترح أعلاه @ . إذا توصلت إلى شيء مختلف ، فيرجى إبلاغي بذلك ، ولكن بالنسبة لكل ما توصلت إليه حتى علمت ، وجدت مشكلة.

من الواضح جدًا بالنسبة لي أنه لا يجب كسر 1. ، أي الكود الذي افترض أنه يمكن تمرير كل سلسلة إلى keyAddBaseName

لماذا ا؟ الأمر غير واضح بالنسبة لي ، لماذا هذا أفضل؟ أسماء ملفات UNIX على سبيل المثال غير مسموح لها أن تحتوي على / ولم يعتقد أحد أن هذه مشكلة. (عدم السماح باستخدام / يجعل تقسيم مسارات UNIX إلى أجزاء أبسط بكثير من استخدام أسماء المفاتيح).

لقد قمنا بالفعل بكسر (تقريبًا) كل جزء من التعليمات البرمجية التي تتفاعل مع Elektra عن طريق إضافة : بعد مساحة الاسم. في الوضع الحالي ، ستستمر المفاتيح المتتالية فقط بدون أي أجزاء مصفوفة وكذلك استبعاد بعض الأشياء ذات الأحرف الخاصة الأخرى في العمل دون الحاجة إلى التغيير. التوافق مع الإصدارات السابقة طويل الأمد.

"2" ليست مهمة جدًا ، فهذه بعض التكرارات التي يمكن إصلاحها.

لن أكون متأكدا من ذلك. في الواقع ، أنا أعرف جزءًا واحدًا فقط من Elektra يفترض حقًا أن keyAddBaseName يفلت من كل شيء وهذا هو elektra-kdb والأدوات التي تنشئ نقاط التثبيت.

يمكن أن تحتوي إدخالات fstab بشكل أساسي على كل شيء بما في ذلك /

لست متأكدا لماذا هذا مناسب؟

أو أسماء mountpoint داخل Elektra.

لإنشاء نقطة التوصيل user:/my/mount ، وضعت الأدوات تكوين نقطة التوصيل تحت system:/elektra/mountpoints/user:\/my\/mount ، ولكن يمكن أيضًا استخدام أي مفتاح فريد آخر أقل مباشرةً من system:/elektra/mountpoints ، لأن نقطة التحميل الفعلية هي قيمة مثل system:/elektra/mountpoints/user:\/my\/mount/mountpoint . قد يكون AFAICT system:/elektra/mountpoints أيضًا مصفوفة. لم أجد أي مكان يستدعي keyBaseName على مفتاح أدنى مباشرة من system:/elektra/mountpoints .

قد يكون هناك مكان يستخدم mountGetMountpoint أو mountGetBackend للحصول على نقطة التثبيت وإعادة بناء system:/elektra/mountpoints/user:\/my\/mount/ للوصول إلى بعض التكوينات ، ولكن يمكن حل ذلك بسهولة عن طريق إضافة system:/elektra/mountpoints key الذي يتم تخزين التكوين أدناه كحقل لـ struct _Backend .

باختصار:

الحد الأدنى من المتطلبات هو أنه من الممكن تمرير أي سلسلة إلى keyAddBaseName واستعادة نفس السلسلة عند طلب الاسم الأساسي بـ keyBaseName

هذا سهل. لكن دمجها مع " keyAddBaseName يجب قبول كل السلاسل" صعب جدًا أو شبه مستحيل.

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

نعم ، لكنني لن أسميها مشكلة بل تحد. نريد أفضل إلكترا ممكن وبالطبع تحدث أهداف متناقضة في بعض الأحيان.

كما قلت ، الحل الوحيد هو تقديم نظام مقيد للغاية ، مثل ذلك الذي يحتوي على @ المقترح أعلاه.

نعم ، أرى أيضًا أنه لن يكون من الممكن الحصول على كل شيء. مع هروب المصفوفة ، نحن بالفعل مقيدون تمامًا بالبادئة الهروب ، أي لا يمكننا الهروب من الأحرف الأخرى داخل الأسماء الأساسية.

لكن هذا الهروب البادئة قد يكون كافيا. ويجب أن يكون هذا قابلاً للتوسيع ليشمل جميع الشخصيات المقترحة أعلاه. سيكون القيد إما أن جزء اسم المفتاح بالكامل قد تم تجاوزه أو لا شيء على الإطلاق.

بالطبع لن يكون الهروب بطريقة سحرية ولكن التطبيقات ستحتاج إلى التحقق مما إذا كان معنى keyBaseName قد تم حذفه أم أننا نقدم keyUnescapedBaseName مختلفًا بحيث يمكن لمستخدمي واجهة برمجة التطبيقات الحصول على السلسلة مع هروب بادئة أو بدونها.

لماذا ا؟ الأمر غير واضح بالنسبة لي ، لماذا هذا أفضل؟ لا يُسمح لأسماء ملفات UNIX على سبيل المثال باحتواء / ولم يعتقد أحد أن هذه كانت مشكلة. (عدم السماح / يجعل تقسيم مسارات UNIX إلى أجزاء أسهل بكثير من تقسيم مسارات UNIX).

إنها مشكلة لكل شخص يستخدم متصفح الملفات. تحتوي بعض التطبيقات على تقنيات ترميز URL للحصول على / في أسماء الملفات. الحل الأكثر حداثة هو استخدام حرف Unicode "DIVISION SLASH" (U + 2215) للشرطات المائلة.

علاوة على ذلك ، ضع في اعتبارك أن السبب الكامل لوجود Elektra هو أن دلالات نظام ملفات UNIX ليست مناسبة للتكوين. في التكوين التسلسل التعسفي لأسماء الأجزاء الرئيسية بما في ذلك / شائعة الاستخدام وبالتالي يجب دعمها. على سبيل المثال في YAML / الأحرف المسموح بها في أجزاء اسم المفتاح وأيضًا في TOML توجد "مفاتيح مقتبسة".

لقد قمنا بالفعل بكسر (تقريبًا) كل جزء من التعليمات البرمجية التي تتفاعل مع Elektra عن طريق إضافة: بعد مساحة الاسم. في الوضع الحالي ، ستستمر المفاتيح المتتالية فقط بدون أي أجزاء مصفوفة وكذلك استبعاد بعض الأشياء ذات الأحرف الخاصة الأخرى في العمل دون الحاجة إلى التغيير. التوافق مع الإصدارات السابقة طويل الأمد.

نعم ، وأنا ممتن للغاية لأنك تفعل هذا. لم أكن لأتمكن من القيام بذلك بمفردي.

لن أكون متأكدا من ذلك. في الواقع ، أنا أعرف جزءًا واحدًا فقط من Elektra يفترض حقًا أن keyAddBaseName يفلت من كل شيء وهو elektra-kdb والأدوات التي تنشئ نقاط التحميل.

جزء آخر هو SSIDs. لم يكن هذا مثالًا اصطناعيًا ولكن شركة Broadcom قامت بتنفيذ ذلك لأجهزة البلوتوث الخاصة بهم. لذلك يعتمدون على أنه يمكنهم إضافة أي اسم أساسي.

هذا سهل. لكن دمجها مع "keyAddBaseName يجب قبول جميع السلاسل" صعب جدًا أو شبه مستحيل.

نعم ، صعب جدًا ولكنه أيضًا ميزة فريدة لطيفة جدًا لم تكن موجودة حتى في UNIX من قبل. يمكننا أن نفخر بذلك.

على سبيل المثال في YAML / الأحرف المسموح بها في أجزاء اسم المفتاح وأيضًا في TOML توجد "مفاتيح مقتبسة".

هذا في الواقع ما اعتقدت أنه يمكننا تقديمه ، انظر أدناه.

أعتقد أن كل هذا يمكن حله عن طريق إدخال شيء مشابه لـ "المفاتيح المقتبسة". سأسميهم _أجزاء رئيسية_.

إذا كان الجزء الرئيسي يبدأ بـ @ (يمكن أن يكون حرفًا آخر بالطبع) ، فإن الجزء الرئيسي التالي هو _literal key part_. يمكن أن يحتوي جزء المفتاح _literal_ على أي تسلسل بايت يتضمن صفر بايت.

شكلها الذي لم يتم تجاوزه هو كما يلي:

• يبدأ جزء المفتاح _literal بحرف @ .
• مزيد من الأحرف @ تم ترميزها كـ @@ .
• تم ترميز صفر بايت كـ @0 .
• قد لا يحدث @ بطريقة أخرى.
• كما هو الحال دائمًا ، ينهي صفر بايت الجزء الأساسي.

يختلف النموذج الذي تم تجاوزه قليلاً ، للسماح بطباعة أسهل:

• يبدأ جزء المفتاح _literal بحرف @ .
• لم يتم إنهاء جزء المفتاح _literal بواسطة / . فقط @ متبوعًا بـ / أو صفر بايت (نهاية السلسلة) ، ينهي جزء المفتاح _literal.
• يمكن ترميز أي بايت على أنه @XX@ ، حيث XX هو الشكل السداسي العشري للبايت. لذلك يجب ترميز الأحرف @ كـ @40@ .

يقبل الآن keySetBaseName و keyAddBaseName أي جزء مفتاح صالح لم يتم تجاوزه كوسائط. قاموا بتعيين / إضافة وسيطتهم غير المعدلة باعتبارها الجزء الأخير من اسم المفتاح الذي لم يتم تجاوزه. لذلك ، سيعيد keyBaseName نفس الوسيطة. بالإضافة إلى ذلك keySetBaseName و keyAddBaseName بتحويل الجزء الذي لم يتم تجاوزه إلى شكله المهرب وقم بتعيينه / إضافته كآخر جزء من الاسم الذي تم حذفه.

لحل مشكلة "نريد إضافة أي شيء كجزء أساسي" ، نقدم:

size_t keySetLiteralBaseName (Key * key, char * bytes, size_t size);
size_t keyAddLiteralBaseName (Key * key, char * bytes, size_t size);

تقبل هذه الدالات تسلسل أي بايت كوسيطة bytes . ثم يقومون بتحويل الوسيطة إلى جزء مفتاح حرفي غير معطل _ عن طريق تسبقها بـ @ ، واستبدال @ بـ @@ وصفر بايت بـ @0 . ثم يتم تمرير هذا إلى keySetBaseName أو keyAddBaseName .

لتسهيل فك شفرة الجزء الأساسي من المفتاح ، يمكننا إضافة وظائف فك التشفير إلى واجهة برمجة التطبيقات العامة أيضًا.

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

keySet / AddLiteralBaseName هو اقتراح لإضافة ميزة جديدة. ليس لدينا حاليًا طريقة لتشفير وحدات البايت الفارغة في أسماء المفاتيح. عندما يحتاج شخص ما هذا ، يمكننا العودة إلى اقتراحك.

ومع ذلك ، في الوقت الحالي ، نحتاج إلى دلالات جيدة لـ keyAdd / SetBaseName. كما هو موضح طويلًا جدًا ، يجب أن يكون هذا بشكل مثالي أي سلسلة ، وإلا فإن العديد من المكونات الإضافية والتطبيقات ستكون عربات التي تجرها الدواب لأنهم لا يتوقعون أن بعض السلاسل لن تعمل. #_10 هو جزء صالح لاسم المفتاح ، ويمكن استخدامه كجزء من اسم المفتاح في جميع مكونات أو تطبيقات التخزين بشكل أساسي ، ولا يمكننا مناقشة ذلك. من المؤكد أنها ليست فكرة جيدة أن تترك مكونًا إضافيًا للتخزين يفشل لأنه وجد #_10 مكان ما كجزء من اسم المفتاح أثناء التحليل. وليس من الجيد أيضًا مطالبتهم باستخدام واجهة برمجة تطبيقات مختلفة مع وسيطة حجم إذا لم يكن لديهم وحدات بايت فارغة على أي حال. في الواقع ، مثل هذه الحالات مثل #_10 أو / لا تحتاج إلى معالجة خاصة هو سبب وجود keyAdd / SetBaseName.

بالمناسبة. ربما يكون من الأفضل أن نلتقي ، على سبيل المثال يوم الثلاثاء؟

ليس لدينا حاليًا طريقة لتشفير وحدات البايت الفارغة في أسماء المفاتيح. عندما يحتاج شخص ما هذا ، يمكننا العودة إلى اقتراحك.

هذه هي النقطة الأقل أهمية في الاقتراح. لا يسمح إلا بصفر بايت ، لأنني لا أرى سببًا لعدم السماح بذلك.

على أي حال ، هناك بالفعل حالة استخدام:

جزء آخر هو SSIDs. لم يكن هذا مثالًا اصطناعيًا ولكن شركة Broadcom قامت بتنفيذ ذلك لأجهزة البلوتوث الخاصة بهم. لذلك يعتمدون على أنه يمكنهم إضافة أي اسم أساسي.

بصرف النظر عن حقيقة أن SSIDs لا علاقة لها بالبلوتوث ، فإن EEE 802.11 يحدد بوضوح SSID على أنه أي تسلسل بايت يصل طوله إلى 32 بايت. لذا فإما أن تقوم Broadcom بالفعل ببعض المعالجة المسبقة للتعامل مع صفر بايت أو أن كودها به أخطاء بالفعل. على أي حال ، من الواضح أن هذه حالة استخدام لتشفير صفر بايت في أسماء القواعد الأساسية.

على أي حال ، ليس لدي أي فكرة عن الملحقات المستقبلية المحتملة لمجموعة الأحرف الخاصة ، ولكن بالنسبة للمجموعة الحالية ، أعتقد أن الحل المطبق في # 3115 قد يعمل كما هو.

إذا جربنا السيناريو من https://github.com/ElektraInitiative/libelektra/issues/2698#issuecomment -554680422 في هذا الإصدار ، يحدث ما يلي:

يؤدي استدعاء keyAddBaseName (key, "#_10") في كل من الجزء الأخير من key->key و key->ukey الذي يمثل #_10 . لماذا ا؟ لأن #_10 عنصر مصفوفة صالح. نعم ، إذا كان #_10 عبارة عن SSID فلن نراه كعنصر مصفوفة ، لكن استخدام # سيتطابق معه ، لكن هل هذا مهم حقًا؟

إذا أخذنا عنصر مصفوفة غير صالح مثل #10 أو #abc ، سيتم إفلات keyAddBaseName وسيكون الجزء الأخير من الاسم الذي لم يتم إلغاؤه هو #10 أو #abc ، بينما سيكون الجزء الأخير من الاسم المهرب \#10 أو \#abc .

لم أفكر بعد في القواعد النظرية التي نحتاجها لجعل هذا العمل مناسبًا للإضافات المستقبلية ، لكن في الوقت الحالي أعتقد أنه يمكننا ترك الأمر على هذا النحو. سيكون من الجيد أن يكون لديك عناصر مصفوفة بدون حرف البداية ، لكن هل هذا مهم حقًا؟ ملحقات التخزين مجانية لتشفير المصفوفات بشكل مختلف ، إذا كانت لديهم مشكلة مع الحرف # وبالنسبة لسطر الأوامر ، يجب علينا فقط إضافة أوامر kdb array* تأخذ معلمات عدد صحيح عادي ، على سبيل المثال kdb arrayset /my/array 10 a .

بالمناسبة. ربما يكون من الأفضل أن نلتقي ، على سبيل المثال يوم الثلاثاء؟

الثلاثاء سيء بالنسبة لي ... سأرسل لك بريدًا إلكترونيًا.

بصرف النظر عن حقيقة أن SSID ليس لها علاقة بالبلوتوث ،

قصدت أجهزة Blueray (التي لديها إمكانية wifi).

يعرّف EEE 802.11 بوضوح SSID بأنه أي تسلسل بايت يصل طوله إلى 32 بايت. لذا فإما أن تقوم Broadcom بالفعل ببعض المعالجة المسبقة للتعامل مع صفر بايت أو أن كودها به أخطاء بالفعل. على أي حال ، من الواضح أن هذه حالة استخدام لتشفير صفر بايت في أسماء القواعد الأساسية.

نعم كلامك صحيح. لكنها ميزة جديدة. أي سلسلة في keySetBaseName ليست ميزة جديدة.

لأن # _10 عنصر صفيف صالح. نعم ، إذا كان # _10 عبارة عن SSID ، فلن نراه كعنصر مصفوفة ، لكن الالتفاف مع # سيطابقه ، لكن هل هذا مهم حقًا؟

لا هذا لا يهم.

سيكون من الجيد أن يكون لديك عناصر مصفوفة بدون حرف البداية ، لكن هل هذا مهم حقًا؟

لا ، الشيء الأكثر أهمية هو أنه يمكن تغذية أي سلسلة إلى keySetBaseName ، ويعيد keyBaseName ما تم تغذيته من قبل. مع الحاجة إلى شخصيات البداية في المصفوفات يمكنني بالتأكيد (ولحسن الحظ) العيش.

[...] وبالنسبة لسطر الأوامر ، يجب علينا إضافة أوامر kdb array * التي تأخذ معاملات عدد صحيح عادي ، مثل kdb arrayset / my / array 10 a.

تبدو كخطة جيدة.

بعد إعادة فحص كل شيء ، أعتقد أن هناك صراعًا واحدًا فقط. لا يمكن توحيد البيانات التالية.

1. قد يحتوي جزء المفتاح الذي لم يتم تجاوزه على أي بايت ليس صفراً.
2. يمكن أن تحدد سلسلة فرعية لجزء رئيسي لم يتم تجاوزه خاصية جزء المفتاح الذي لم يتم تجاوزه.

في حالتنا الخاصة. العبارة الأولى تأتي من ضمانات keyBaseName et al. مع حقيقة أنك لا تريد أن يرفض keyAddBaseName وسيطة. بالإضافة إلى ذلك ، فإن الاقتراح "الأجزاء الرئيسية غير المستغلة التي تبدأ بـ # هي دائمًا مؤشرات مصفوفة" هي حالة خاصة من 2.

هذا يعني بشكل أساسي الاحتفاظ بـ 1 ، وهو ما نريده ، يصبح من الضروري إعادة التحقق دائمًا من جزء مفتاح كامل لم يتم تجاوزه ، إذا كنت تريد اختبار خاصية معينة. على وجه الخصوص ، يجب عليك التحقق من جزء المفتاح الكامل الذي لم يتم تجاوزه لتعرف أنه فهرس مصفوفة. أجد هذا الوضع مؤسفًا ، لكن يبدو أنه لا مفر منه.

هذا يعني أيضًا أنه لا يزال بإمكاننا عمل شيء "الأجزاء الرئيسية التي تم تجاوزها والتي تتكون بالكامل من أرقام هي مؤشرات مصفوفة". قد يكون التأثير الجانبي هو أنه في مثال SSID keyAddBaseName (key, "#_10") سينتج اسم مهرب ينتهي بـ /10 بدلاً من /#_10 . ولكن بما أنك قبلت بالفعل حقيقة أن keyAddBaseName (key, "#abc") ينتج اسمًا مهربًا ينتهي بـ /\#abc ، أفترض أن هذا لن يكون مشكلة أيضًا؟
سيكون تنفيذ هذا مهمة أكبر ، لذا ستكون متابعة للعلاقات العامة # 3115. سأحتاج إلى التحقق من أن كل شيء يعمل مع فهارس المصفوفات يستخدم بالفعل الاسم الذي لم يتم تجاوزه ، بالإضافة إلى تحديث كل شيء يقوم بإنشاء مفاتيح بأجزاء مصفوفة.

في الواقع 2. ليست هناك حاجة بالضرورة. يمكننا أيضًا تخزين سلسلة ثالثة تحتوي على الاسم الأساسي الذي سيتم إرجاعه (ربما عندئذٍ فقط عندما تكون هناك حاجة فعلية لعدم إضاعة الكثير من الذاكرة).

سيكون تنفيذ هذا مهمة أكبر

هذا ليس جيدًا ، نحتاج أيضًا إلى إنهاء هذا بطريقة ما. ربما تنقذنا السلسلة الثالثة ، يمكننا تحسين ذلك لاحقًا (إذا لزم الأمر).

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

في الواقع 2. ليست هناك حاجة بالضرورة.

كما قلت ، كان اقتراحًا. سيكون من الجيد أن يكون لديك ، لكن للأسف لا يعمل.

يمكننا أيضًا تخزين سلسلة ثالثة تحتوي على الاسم الأساسي الذي سيتم إرجاعه (ربما عندئذٍ فقط عندما تكون هناك حاجة فعلية لعدم إضاعة الكثير من الذاكرة).

سنحتاج إلى تخزين إصدار ثالث كامل من اسم المفتاح ، وإلا فإن keySetBaseName (key, NULL) سيعمل بشكل صحيح.

في الوقت الحالي ، لا توجد العديد من الخصائص التي يمكن أن يمتلكها جزء رئيسي. على الأقل ليست خصائص مثيرة للاهتمام في جميع أنحاء إلكترا. "هل هو جزء فهرس مصفوفة؟" هو في الواقع الوحيد الذي يمكنني التفكير فيه. إذا كان لدينا في المستقبل المزيد من الخصائص (على سبيل المثال إذا أضفنا مفهوم "العناصر النائبة السياقية" إلى الصميم) ، يمكننا التفكير في التحسينات.

هذا ليس جيدًا ، نحتاج أيضًا إلى إنهاء هذا بطريقة ما.

أعلم ، وهذا هو بالضبط السبب الذي جعلني أقول إنني لن أفعل ذلك في # 3115. إذا قررنا أننا بحاجة إليها ، سأفتح علاقات عامة أخرى. هذه العلاقات العامة الثانية سوف تتطلب الكثير من العمل وستكون تغيير جذري. ومع ذلك ، يجب أن يكون تغيير كسر أصغر بكثير ويجب ألا تتأثر (معظم) العلاقات العامة الأخرى المتزامنة بقدر ما ستتأثر عندما ندمج رقم 3115.

إما أن نضع قائمة كاملة بالمتطلبات ذات الأولوية في قرار ما أو نلتقي بها؟

سأكتب الوثائق ، بما في ذلك القرار ، عند الانتهاء من رمز # 3115. السؤال المفتوح الآن هو:

1. بخلاف / و \ ، ما هي الأحرف التي يمكن أن يكون لها معنى خاص في بداية الجزء الرئيسي؟
   في # 3115 ، هذه العناصر حاليًا هي # ، % ، . و @ .
2. ما المعنى الخاص؟ يمكن أن يكون هذا مختلفًا اعتمادًا على باقي الجزء الرئيسي.
   في # 3115 لدينا ما يلي:
   
   
   
   • يعني # جزء المصفوفة ، إذا كان باقي الجزء الرئيسي عبارة عن أرقام فقط أو أول n شُرط سفلية ثم n + 1 أرقام ( n >= 0 ) ولا شيء آخر. جزء من # ليس له معنى خاص بشكل عام (يمكن أن يعني أن الصفيف يتدفق إلى بعض أجزاء Elektra). أي جزء آخر يبدأ بـ # يعني أن اسم المفتاح غير صالح.
   
   
   • % يعني الجزء الفارغ إذا كان الجزء هو % . أي جزء آخر يبدأ بـ % يعني أن اسم المفتاح غير صالح.
   
   
   • . له معنى خاص فقط إذا كان الجزء . أو بالضبط .. . جميع الأجزاء الأخرى التي تبدأ بـ . ليس لها معنى خاص حاليًا ، أي أن اسم المفتاح غير صالح. (في السابق كان الجزء الذي يبدأ بـ . مفتاحًا غير نشط)
   
   
   • @ محجوز. أي جزء يبدأ بـ @ يعني أن اسم المفتاح غير صالح.
   
   
3. هل ينبغي دائمًا السماح بالهروب من الأحرف الخاصة من 1 أم عند الحاجة فقط؟
   في # 3115 ، يُسمح دائمًا بالهروب.
4. هل نريد أن يتم تفسير الأجزاء الرئيسية التي تتكون بالكامل من أرقام كأجزاء مصفوفة؟ إذا كان الأمر كذلك ، فما هو التمثيل القانوني؟ مجرد أرقام فقط ، بدءًا من # ثم أرقام فقط أو نفس النسخة التي لم يتم تجاوزها ، مثل # والشرطات السفلية؟
   في # 3115 ، نطلب دائمًا أجزاء المصفوفة لتبدأ بـ # وتمثيلها الأساسي هو نفسه الذي لم يتم تجاوزه.

إجاباتي المقترحة هي:

1. # و % و . و @ و $ و & و ? يكفي للاستخدامات المستقبلية المحتملة. على وجه الخصوص ، أعتقد أننا لا يجب أن نحتفظ بـ _ لن يؤدي إلا إلى مشاكل.
2. كما لدينا في # 3115. $ و & و ? محجوز للاستخدام في المستقبل مثل @ .
3. دائما مسموح.
4. أنا شخصياً ضد ذلك. إن وجود حرف البداية يجعل من السهل تحديد أجزاء المصفوفة عند النظر إلى أسماء المفاتيح. كما هو مقترح في # 2698 ، يجب حل أي تضارب مع الأحرف الخاصة في تنسيقات التخزين عن طريق ملحقات التخزين وليس الأساسية ويجب أن تحتوي الأداة kdb فقط على أوامر صفيف خاصة.

شيء غير مرتبط قليلاً: قد يكون من الممكن تحويل directoryvalue إلى مكتبة (أو حتى جعلها جزءًا من النواة) ومنحها واجهة خاصة تسمح بإنشاء مفاتيح لن تكون ممكنة من خلال واجهة برمجة التطبيقات العامة. ثم لا داعي للقلق بشأن الاصطدامات بسبب الاسم __directoryvalue . سيتم استخدام أحد الأحرف المحجوزة لذلك. لم أفكر كثيرًا في الأمر ، لكنها قد تكون فكرة جيدة ، نظرًا لأن معظم تنسيقات التخزين جيدة للقراءة البشرية لا تدعم المفاتيح ذات القيمة والمفاتيح أدناه.

بخلاف / و \ ، ما هي الأحرف التي يمكن أن يكون لها معنى خاص في بداية الجزء الرئيسي؟
في # 3115 هذه حاليًا هي # ، ٪ ،. و @.

هذا ما تدور حوله هذه المشكلة بشكل أساسي: تجميع الأحرف التي من المحتمل أن يكون لها معنى خاص (الآن أو محجوز).

هل ينبغي دائمًا السماح بالهروب من الأحرف الخاصة من 1 أم عند الحاجة فقط؟

نعم ، مسموح به دائما.

هل نريد أن يتم تفسير الأجزاء الرئيسية التي تتكون بالكامل من أرقام كأجزاء مصفوفة؟ إذا كان الأمر كذلك ، فما هو التمثيل القانوني؟ فقط أرقام أيضًا ، بدءًا من # ثم بالأرقام فقط أو بنفس النسخة التي لم يتم تجاوزها ، مثل # والشرطات السفلية؟

هذا يعتمد بشكل كبير على خصائص الأسماء الأساسية التي نخسرها. من منظور المستخدم ، من "الجميل" إذا لم تكن هناك حاجة إلى # ، فمن منظور API ، من المهم جدًا أن يعمل keySet/AddBaseName فقط.

على وجه الخصوص ، أعتقد أنه لا ينبغي لنا أن نتحفظ لأن هذا سيؤدي فقط إلى مشاكل.

ولتغيير globbing إلى * ؟

إن وجود حرف البداية يجعل من السهل تحديد أجزاء المصفوفة عند النظر إلى أسماء المفاتيح.

لا أعتقد أنها مشكلة كبيرة: من السهل أيضًا تحديد الأرقام داخل سلسلة:

user/here/is/a/test/1/not/a/number/4/here/is/a/number

ثم لا داعي للقلق بشأن الاصطدامات بسبب الاسم __directoryvalue.

إذا تم تنفيذه بشكل صحيح ، فلا داعي للقلق أيضًا إذا تم تنفيذه كمكوِّن إضافي ، فقد يتخطى المكون الإضافي __directoryvalue الموجود بالفعل.

حلمي هو أن keySetBaseName سوف يهرب من _directoryvalue (علامة سفلية واحدة أو @ ستكون كافية) ، لكن المكون الإضافي directoryvalue سيستخدم keyAddName للحصول على _directoryvalue خام داخل اسم المفتاح. (والتي ستكون محمية لأن الشرطة السفلية أو @ هي حرف محجوز لا يستخدم للتطبيقات).

نأمل أن نتمكن من مناقشة هذا اليوم ، وآمل بهذه الطريقة أن نتمكن من الوصول بسهولة إلى الخاتمة.

هذا يعتمد بشكل كبير على خصائص الأسماء الأساسية التي نخسرها.

كما قلت ، لا ينبغي أن نفقد أي شيء مقارنة بالحالة الحالية # 3115 ، لكننا أيضًا لن نكسب الكثير بالضرورة. السؤال الرئيسي هو ما مقدار العمل الإضافي الذي نريد استثماره في تغيير الاسم الرئيسي. دعونا نتحدث عن هذا اليوم.

ولتغيير globbing إلى * ؟

* له بالفعل معنى لمكتبة globbing. إنه يعني أي جزء رئيسي. # يطابق أجزاء المصفوفة فقط و _ يطابق الأجزاء غير المصفوفة.

لا أعتقد أنها مشكلة كبيرة: من السهل أيضًا تحديد الأرقام داخل سلسلة

قد يكون هذا أنا فقط ، لكنني لم أرصد /1/ في البداية.

إذا تم تنفيذه بشكل صحيح ، فلا داعي للقلق أيضًا إذا تم تنفيذه كمكوِّن إضافي ، فقد يتخطى المكون الإضافي __directoryvalue الموجود بالفعل.

انظر # 3256 لحل بديل باستخدام metakeys.

حلمي هو أن keySetBaseName سوف يهرب _directoryvalue

أنا ضد ذلك بشدة. لا ينبغي أن يهتم النواة بأي شكل من الأشكال بما تفعله المكونات الإضافية أو المتطلبات التي لديها. كما أنه يشكل سابقة سيئة. ماذا لو كان مكون إضافي آخر يستخدم _averyspecialkey لشيء ما؟ هل سنقوم بتحديث keySetBaseName كل مرة يحدث هذا؟

نتيجة الحديث:

• يبدو أن خصائص الاسم الأساسي بالفعل أكثر أو أقل كما كانت من قبل
• ستستمر المصفوفات في البدء بـ # (لكن _ لن تكون هناك حاجة)
• سيتم تخطي الأحرف أعلاه إذا كانت في الموضع الأول ، باستثناء: #
• keySetBaseName لن ولا يمكن تحديثه للأحرف الجديدة ، القائمة أعلاه (عند الانتهاء) هي قائمة كاملة لـ Elektra 1.0

سيتم تخطي الأحرف أعلاه إذا كانت في الموضع الأول ، باستثناء: #

يتم تحديد السلوك الحالي (في # 3115) لـ keySetBaseName و keyAddBaseName بواسطة هذه الوظيفة:

https://github.com/ElektraInitiative/libelektra/blob/9e91654ca72e6cd58b3b54892e78b5a5b2810214/src/libs/elektra/keyname.c#L1360 -L1462

نحن نهرب فقط عندما تكون هناك حاجة لتجنب الهروب غير الضروري بالاسم الهارب.

أيضًا بما أنك سألت ، ما إذا كانت هناك علاقة 1: 1 بين اسم المفتاح الذي تم تجاوزه وغير المهرب:

لا يوجد. قررنا السماح بالهروب غير الضروري:

هل ينبغي دائمًا السماح بالهروب من الأحرف الخاصة من 1 أم عند الحاجة فقط؟

نعم ، مسموح به دائما.

هذا يعني أن ، على سبيل المثال ، /key/%abc و /key/\%abc أسماء مفاتيح تم تجاوزها مختلفة لنفس اسم المفتاح الذي لم يتم إلغاء إلغاءه. وهي تلك التي تحتوي على مساحة اسم متتالية والجزئين key و %abc .

إذا أردنا التأكد من وجود علاقة 1: 1 ، فيمكننا إما أن نقول أن الهروب مسموح به فقط عند الحاجة (لا يعجبك ذلك) ، أو إزالة الخطوط المائلة العكسية غير الضرورية أثناء خطوة تحديد العنوان الأساسي.
في أي حال ، تتطلب العلاقة 1: 1 أن يتصرف keySetBaseName و keyAddBaseName كما هو موصوف أعلاه ، أي يجب أن يعرف متى يجب الهروب.

أنا شخصياً لا أعتقد أن العلاقة 1: 1 مطلوبة. نحتاج فقط إلى علاقة: 1 لجعل عمل ksLookup . عادة لا تكون مشكلة ، إذا بحثنا عن /key/\%abc واسترجعنا /key/%abc أو العكس.

شكرًا لك على التحقيق في سلوك رحلة الذهاب والإياب. نعم ، البحث ليس مشكلة كبيرة (إنه بالفعل 1: n بسبب التتالي) ولكن تلك المفاتيح ذات الأسماء المختلفة تزيل نفسها عند إلحاقها بمجموعة المفاتيح أمر قبيح. وبالطبع فإن عدم ذهابًا وإيابًا هو هدف مهم آخر: يجب أن تكون كل مجموعة مفاتيح متطابقة تمامًا بعد التسلسل والتسلسل ، ولن يتم تقديم هذا إذا كانت \% و % متطابقة "في التمثيل الداخلي.

هل لديك حل لمشكلة ks Append و Round-tripping؟

إنها مسألة تعريف. ما الذي يميز المفتاح بشكل فريد؟

الجواب الفني هو الاسم الذي لم يتم تجاوزه. إنه ما تستخدمه KeySet للتمييز بين المفاتيح.
يجب على المستخدمين فقط أن يعتادوا على معرفة متى يكون اسمان رئيسيان متماثلين. إنه نوع مشابه لإكتشاف أن الكسور 2/3 و 4/6 هي نفسها.

إذا كنت لا تزال تريد العلاقة 1: 1 ، فيجب السماح بالهروب فقط عند الضرورة. هذا ليس مجهودًا إضافيًا للتنفيذ ، ولكنه قد يكون مزعجًا للمستخدمين.

إنها مسألة تعريف. ما الذي يميز المفتاح بشكل فريد؟

حتى الآن ، كان قول "الاسم يعرّف مفتاحًا" كافيًا لأن هناك 1: 1 بين هروب وغير مهرب. تم تخزينها فقط لتحسين الأداء. (المكان مقابل الوقت)

أفضل ما إذا كان يمكن أن يبقى على هذا النحو.

إذا كنت لا تزال تريد العلاقة 1: 1 ، فيجب السماح بالهروب فقط عند الضرورة. هذا ليس مجهودًا إضافيًا للتنفيذ ، ولكنه قد يكون مزعجًا للمستخدمين.

لماذا يكون مزعج؟

كانت فكرتي عن \#123 مقابل #123 أنه ليس نفس اسم المفتاح وليس له نفس المعنى (أحدهما يعني حرفيا #123 ، والآخر هو 124 إدخال مجموعة). كلاهما سيكون لهما أسماء مختلفة هاربة وغير مهرب.

إذا كان لديهم الآن نفس الاسم الذي لم يتم تجاوزه ، فيمكننا ببساطة رفض keyAddName(k, "\\#123") . لا فائدة من امتلاكه ، أم أنه موجود؟

كانت فكرتي عن \#123 مقابل #123 أنه ليس نفس اسم المفتاح وليس له نفس المعنى (أحدهما يعني حرفيا #123 ، والآخر هو 124 إدخال مجموعة). كلاهما سيكون لهما أسماء مختلفة هاربة وغير مهرب.

هذا المثال لا يوضح أي شيء. من الواضح أن \#123 و #123 لهما إصدارات مختلفة لم يتم تجاوزها ، وإلا فلن يكون من الممكن الحصول على الجزء الذي لم يتم تجاوزه #123 بأي شكل من الأشكال.

تعتبر المصفوفات أيضًا مثالًا سيئًا ، لأننا قلنا أن # يجب أن يقدم جزء مصفوفة صالحًا أو يتم الهروب منه لتجنب الأخطاء السهلة. بدلاً من ذلك ، دعنا ننظر إلى % .

إذا كان الجزء الذي تم تجاوزه هو /%/ ، نحصل على جزء فارغ لم يتم تجاوزه وإذا كان /\%/ نحصل على الجزء الذي لم يتم إلغاؤه % . من الواضح أن كلاهما يجب أن يكون أجزاء رئيسية تم تجاوزها. حتى الان جيدة جدا.
السؤال الآن حول الأجزاء /%abc/ و /\%abc/ . كلاهما يخططان للجزء الذي لم يتم تجاوزه %abc . وهل كلاهما جائز أم باطل أحدهما؟ إذا كان كلاهما مسموحًا به ، فليس لدينا علاقة 1: 1.

هذا ما قصدته بـ:

هل ينبغي دائمًا السماح بالهروب من الأحرف الخاصة من 1 أم عند الحاجة فقط؟

الذي أجبت عليه:

نعم ، مسموح به دائما.

وهو ما فسرته على أنه مسموح لكل من /%abc/ و /\%abc/ . أدرك الآن أنك ربما تكون قد قصدت "نعم ، مطلوب دائمًا" ، على سبيل المثال فقط /\%abc/ صالح.

على أي حال...
لدينا خياران هنا:

1. يجب أن يقدم الحرف المحجوز جزءًا صالحًا له معنى خاص ، أو يجب تخطيه.
   في المثال أعلاه ، هذا يعني أن /\%abc/ هو الصحيح.
2. يجب فقط الهروب من الحرف المحجوز ، عندما يكون للجزء معنى خاص بدون الهروب.
   في المثال أعلاه ، هذا يعني أن /%abc/ صالح.

يمكن إجراء الاختيار بشكل مستقل لكل من الأحرف المحجوزة. يمكن اختيار خيار واحد فقط من هذه الخيارات لكل حرف للاحتفاظ بعلاقة 1: 1.

في # 3115 ، يوجد حاليًا الخيار 1 مقابل # والخيار 2 مقابل . و % . بالنسبة إلى @ كلا الخيارين متماثلان ، يتطلب الأمر دائمًا الهروب. لا توجد أجزاء صالحة تبدأ بـ @ . يجب أن أتحقق من صحة كل شيء آخر ، لكن أعتقد أن لدينا علاقة 1: 1 في # 3115 الآن.

شكرا لشرح مفصل. نعم ، ليس من المهم أن يكون /%abc/ قابل للإفلات بشرطة مائلة واحدة للخلف. رحلة الجولة هي أكثر أهمية. يمكننا أيضًا استخدام شيء آخر للهروب من هذا (في الطبقة أعلاه).

لا توجد أجزاء صالحة تبدأ بـ @.

كيف ستعمل عندما نخصص معنى @ ؟

يجب أن أتحقق من صحة كل شيء آخر ، لكن أعتقد أن لدينا علاقة 1: 1 في # 3115 الآن.

شكرا لك: 100:

كيف ستعمل عندما نخصص @ معنى؟

أنت محق ، لضمان التوافق في المستقبل ، يتعين علينا اختيار الخيار 1. من السهل رؤية:
/\%abc/ ، /%/ و /\%/ غير صالحة ، لكن /%abc/ غير صالحة. جميع الأجزاء التي تبدأ بـ @ غير صالحة الآن ، لكن البدء بـ \@ مسموح به وسيظل صحيحًا ، إذا أصبحت بعض الأجزاء التي تبدأ بـ @ صالحة.

لقد حذفت مجموعة القواعد التي نشرتها سابقًا ، لأنني لاحظت بعد اللعب بقواعد ANTLR أن القواعد لا تساعد. أعتقد أن وجود علاقة 1: 1 وضمان التوافق مع الإصدارات السابقة عند إعطاء معنى للأحرف المحجوزة أمر مستحيل أساسًا.

لنأخذ @ كمثال. حاليًا فقط الأجزاء التي تبدأ بـ \@ صالحة ، الأجزاء التي تبدأ بـ @ غير صالحة دائمًا. أجزاء من النموذج \@XYZ ( XYZ تعسفية) لم يتم تجاوزها في @XYZ .

الآن قررنا تقديم معنى لـ @ . جميع أجزاء النموذج @XYZ ( XYZ تعسفي) التي يكون فيها المسند foo(XYZ) ( foo هو بعض المسند من السلسلة) هو الآن غير مهرب إلى bar(XYZ) ( bar هي بعض الوظائف التي تعين السلاسل إلى السلاسل). للحفاظ على العلاقة 1: 1 ، يجب علينا بوضوح التأكد من عدم تجاوز أي جزء آخر إلى bar(XYZ) . لكن هذا يعني أن بعض المفاتيح الصالحة حاليًا ستصبح غير صالحة ، لأنه من الممكن حاليًا الحصول على مفاتيح بأسماء عشوائية لا يمكن تجاوزها. هذا يكسر التوافق. (ملاحظة: قد يكون من الممكن الاحتفاظ بالعلاقة 1: 1 وسلوك رحلة الذهاب والإياب الفضفاض بين الإصدارين "لا معنى لـ @ " و "المعنى لـ @ " ، لكن هذا مجرد تغيير كسر مختلف.)

قد يكون لدي حل لهذا ، لكنني أعلم بالفعل أنك لن تعجبك ، لأنه يتضمن عدم السماح ببعض الأسماء التي لم يتم تجاوزها.

أصبح شرح الحل الذي قدمته طويلًا جدًا ، لذلك قمت بوضعه في ملف في # 3115.

الفكرة الأساسية هي:

• لم تعد جميع متواليات البايت أسماء مفاتيح لم يتم تجاوزها بعد الآن. لم تعد بعض سلاسل C صالحة لأجزاء اسم المفتاح التي لم يتم تجاوزها.
• هذا يجعل إثباتًا مستقبليًا لعلاقة 1: 1 بين أسماء المفاتيح التي تم تجاوزها والتي لم يتم تجاوزها ممكنًا. قد تصبح السلاسل أجزاء مفتاح صالحة لم يتم تجاوزها ، ولكن بمجرد أن تصبح السلسلة صالحة ، لا يمكن أن تصبح غير صالحة بعد الآن.

يمكن العثور على الشرح التفصيلي وما يعنيه هنا . يمكنك إضافة تعليقات هنا: https://github.com/ElektraInitiative/libelektra/commit/86d8e7806bfb92e95a7c519e09e95fa278eadb05

شكرا جزيلا لعملك على هذا! sanssecours هل يمكنك إلقاء نظرة عليها إذا أعجبتك الفكرة أيضًا؟

قد يكون لدي حل لهذا ، لكنني أعلم بالفعل أنك لن تعجبك ، لأنه يتضمن عدم السماح ببعض الأسماء التي لم يتم تجاوزها.

بالمناسبة. لا يعني ذلك "لن يعجبني" ، فهو أن لا أحد سيحب Elektra إذا كانت جميع مكونات التخزين الإضافية عربات التي تجرها الدواب لأنها لا تستطيع قبول بعض السلاسل.

هي عربات التي تجرها الدواب لأنها لا تقبل بعض السلاسل

إنها ليست عربات التي تجرها الدواب ، إذا حددناها بهذه الطريقة. تتطلب JSON هروبًا مشابهًا لسلاسل C. لا أحد يشكو من ذلك. سيتطلب أي مكون إضافي من Elektra يستخدم JSON استخدام عدد قليل من عمليات الهروب الأخرى.

في حين أنه يجب أن يكون مرئيًا من التعريفات الأكثر تفصيلاً ، ربما كان ينبغي عليّ أن أصرح صراحةً أنه لا توجد وظائف فعلية مفقودة. إنه أكثر تعقيدًا قليلاً في حالات قليلة.

لكل تسلسل من البايت لا يزال هناك اسم مفتاح واحد لم يتم تجاوزه يمثل هذا التسلسل من البايت. كل ما في الأمر أن التسلسل الأصلي للبايت واسم المفتاح الذي لم يتم تجاوزه والذي يمثله لن يكون دائمًا هو نفسه.

إنها ليست عربات التي تجرها الدواب ، إذا حددناها بهذه الطريقة. تتطلب JSON هروبًا مشابهًا لسلاسل C. لا أحد يشكو من ذلك. سيتطلب أي مكون إضافي من Elektra يستخدم JSON استخدام عدد قليل من عمليات الهروب الأخرى.

أنت تقارن التفاح بالموز هنا. JSON هو تنسيق تسلسل ، ونحن نناقش هنا بنية البيانات (KeySet). على مستوى التسلسل ، لا تزال مكونات التخزين الإضافية بحاجة إلى إلغاء / إلغاء أسماء المفاتيح وقيم المفاتيح بحيث يمكن تمييز الفواصل.

في حين أنه يجب أن يكون مرئيًا من التعريفات الأكثر تفصيلاً ، ربما كان ينبغي عليّ أن أصرح صراحةً أنه لا توجد وظائف فعلية مفقودة. إنه أكثر تعقيدًا قليلاً في حالات قليلة.

بدون واجهة برمجة التطبيقات يصعب معرفة ما تعنيه عبارة "أكثر تعقيدًا قليلاً".

كل ما في الأمر أن التسلسل الأصلي للبايت واسم المفتاح الذي لم يتم تجاوزه والذي يمثله لن يكون دائمًا هو نفسه.

أعتقد أننا يمكن أن نتعايش مع ذلك.

أنا قلق فقط من أن هذا التغيير سيكون كبيرًا جدًا (يبدو أيضًا أن هناك حاجة إلى تعديل في جميع مكونات التخزين الإضافية) ولن نتمكن من إكماله. ربما من الأفضل نسيان الفرز الطبيعي الذي تسبب في معظم هذه المشكلة؟

ربما من الأفضل نسيان الفرز الطبيعي الذي تسبب في معظم هذه المشكلة؟

الفرز الطبيعي لا علاقة له بهذا. AFAIK ، لم يتم ذكره في أي مكان في الاقتراح. تكمن المشكلة في عكس الأحرف لاستخدامها في المستقبل مع تجنب كسر التغييرات.

بدون واجهة برمجة التطبيقات يصعب معرفة ما تعنيه عبارة "أكثر تعقيدًا قليلاً".

API في الاقتراح. في هذه الحالة ، تعني كلمة "أكثر تعقيدًا" الاختيار بين عمليتين ( pushL و pushU ، الأسماء هي عناصر نائبة) بدلاً من استخدام نفس العملية دائمًا ( keyAddBaseName ). وأحيانًا يتم تجاهل الشرطة المائلة للخلف عند مقارنة الأجزاء الرئيسية بالسلاسل.

أنا قلق فقط من أن هذا التغيير سيكون كبيرًا جدًا

إنه تغيير كبير بالطبع ، لكنه سيقلل من التغييرات المستقبلية.

لن نتمكن من الانتهاء منه

حسنًا ، هذا يعتمد كليًا على الموعد النهائي ...

كما تمت مناقشته ، أعتقد أننا يجب أن ننسى هذه المسألة (حجز الشخصيات الخاصة). بدلاً من ذلك ، يجب إجراء عمليات الهروب ذات المستوى الأعلى (مثل المصفوفات # ، % ) أو حجز الأحرف الخاصة ( @ ) مباشرةً في مكونات التخزين الإضافية.

حسنًا ، هذا يعتمد كليًا على الموعد النهائي ...

إذا كنت ترغب في عمل أطروحة ماجستير حول مكتبات البرامج المؤكدة في المستقبل ، فأنت حر في إعادة فتح هذا الموضوع: wink:

كما نوقش [...]

هذا ليس ما أتذكره من المناقشة. اعتقدت أننا وافقنا على إنهاء # 3115 ثم التفكير في هذه المشكلة مرة أخرى.

سأنتهي من رقم 3115 وسأضيف أيضًا بعض الأمثلة وتفسيرات بسيطة باللغة الإنجليزية إلى الاقتراح.

بدلاً من ذلك ، يجب إجراء عمليات الهروب ذات المستوى الأعلى (مثل المصفوفات # ،٪) أو حجز الأحرف الخاصة (@) مباشرةً في مكونات التخزين الإضافية.

هذا بصراحة حل غبي ...

في كل مرة نضيف شيئًا جديدًا لأسماء المفاتيح ، سيتعين علينا تحديث جميع مكونات التخزين الإضافية. هذا هو بالضبط السبب الذي استخدمته ضد الحل الخاص بي (والذي يتطلب ذلك مرة واحدة فقط).

كما أنه لا يتجنب تحديث المكونات الإضافية الآن ، نظرًا لأن AFAIK لا يتعامل أي منهم فعليًا مع أسماء المفاتيح بنسبة 100٪ (أجزاء المصفوفة).

إذا كنت لا تريد اقتراحي حقًا ، فيرجى تقديم سبب ضده ، بدلاً من اقتراح حل لا يحل شيئًا ويكاد يكون نفس القدر من الجهد.

إذا كنت ترغب في عمل أطروحة ماجستير حول مكتبات البرامج المؤكدة في المستقبل

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

هذا ليس ما أتذكره من المناقشة. اعتقدت أننا وافقنا على إنهاء # 3115 ثم التفكير في هذه المشكلة مرة أخرى.

نعم لم ننتهي من المناقشة ولكن:

• توصيتي هي إصلاح الأخطاء المهمة الأخرى ومشاكل سهولة الاستخدام.
• لا أستطيع ولن أمنعك من التفكير في الأمر على أي حال: غمزة:

كما أنه لا يتجنب تحديث المكونات الإضافية الآن ، نظرًا لأن AFAIK لا يتعامل أي منهم فعليًا مع أسماء المفاتيح بنسبة 100٪ (أجزاء المصفوفة).

الرجاء الإبلاغ عن الخلل. يجب أن يكون استخدام المصفوفات كما هو محدد في doc /isions / array.md صحيحًا إذن ، فإن #0 هو "اسم بسيط بلا معنى" ولا تحصل المصفوفات على معنى إلا بمفتاح أسفله مباشرةً يحتوي على "مصفوفة" بيانات وصفية.

إذا كنت لا تريد اقتراحي حقًا ، فيرجى تقديم سبب ضده ،

أنا أحب الاقتراح كثيرا. لكن أشياء مثل # 1074 (وانظر https://github.com/ElektraInitiative/libelektra/projects/9 للمزيد) تعتبر IMHO أكثر أهمية لنجاح Elektra.

بدلاً من اقتراح حل لا يحل شيئًا ويكاد يكون نفس القدر من الجهد.

ماذا تقصد بذلك؟ كان اقتراحي الأخير هو ببساطة عدم حجز الأحرف وترك الأمر لمكونات التخزين لفعل ما يريدون. لا أرى أي جهد في "تنفيذ" هذا الاقتراح (إنه NOP).

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

ربما يكون هذا كافياً بالفعل لأطروحة الماجستير إذا أنهيت البراهين. ومع ذلك ، لم أنظر في الأعمال ذات الصلة ، ربما قام شخص آخر بالفعل بشيء كهذا.

يجب أن يكون استخدام المصفوفات كما هو محدد في doc /isions / array.md صحيحًا

قد يكون هذا هو الحال ، لكن البرنامج التعليمي لمكونات التخزين الإضافية لا يوافق ، بل إنه يوضح أن yamlcpp لا يعمل بهذه الطريقة.

لكن أشياء مثل # 1074 هي IMHO أكثر أهمية بكثير لنجاح Elektra.

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

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

كان اقتراحي الأخير هو ببساطة عدم حجز الأحرف

لقد ذكرت حجز @ .

اترك الأمر متروكًا لمكونات التخزين الإضافية لتفعل ما تريد

هذا يؤدي فقط إلى عدم التوافق. بالطبع لا يمكننا منع مكونات التخزين الإضافية من استخدام تنسيق مختلف تمامًا ، ولكن عدم إعطاء أي إرشادات هو مجرد طلب للمشاكل.

قد يكون هذا هو الحال ، لكن البرنامج التعليمي لمكونات التخزين الإضافية لا يوافق ، بل إنه يوضح أن yamlcpp لا يعمل بهذه الطريقة.

sanssecours هل يمكنك النظر في هذا؟ إذا تعرفنا على المصفوفات فقط بسبب الهيكل (الأسماء ذات #0 ) فلن تقوم KeySet بإعطاء إكرامية مستديرة.

من المحتمل أن يستغرق الأمر وقتًا طويلاً أو أطول للعثور على حل وتنفيذه

نعم ، لكن user / dir mountpoint هو شيء يواجهه كل مستخدم في Elektra بشكل متكرر. إذا احتجنا إلى أي وقت مضى الأحرف المحجوزة غير معروف.

لقد ذكرت حجز @.

نعم ، يمكن لمكونات التخزين الإضافية حجز ما تريده والهروب منه.

هذا يؤدي فقط إلى عدم التوافق. بالطبع لا يمكننا منع مكونات التخزين الإضافية من استخدام تنسيق مختلف تمامًا ، ولكن عدم إعطاء أي إرشادات هو مجرد طلب للمشاكل.

انا اوافق تماما. ربما يكرهنا بعض الناس في بعض السنوات لأننا لم نحتفظ ببعض الشخصيات (ولكن ربما لا). لكنني متأكد تمامًا من أنه لن يساهم في نجاح Elektra 1.0. لأكون واضحًا: أنا لا أعارض تمامًا تنفيذه ولكن هناك أشياء أخرى (https://github.com/ElektraInitiative/libelektra/projects/9) هي IMHO أعلى بكثير في قائمة الأولويات. أنت حر في عدم الموافقة عليه وتنفيذه على أي حال. لن أرفض PR طالما أنها لا تصبح معقدة للغاية بالنسبة لمكونات التخزين (ويتم إصلاح جميع المكونات الإضافية). ولكن هناك خطر كبير بأن الأشياء الأخرى (وهو أمر ضروري لنجاح) لا يحصل تنفيذها ولن تستخدم إلكترا في مشاريع مهمة مثل KDE.

sanssecours هل يمكنك النظر في هذا؟ إذا تعرفنا على المصفوفات فقط بسبب الهيكل (الأسماء ذات #0 ) فلن تقوم KeySet بإعطاء إكرامية مستديرة.

لقد قمت بتحديث سلوك YAML CPP والمكوِّن الإضافي Directory Value في PR 3357. يحدِّث طلب السحب أيضًا جزءًا من الوثائق لأخذ البيانات الوصفية الإلزامية array في الاعتبار.

لقد قمت الآن بتحديث الاقتراح في # 3447. آمل أن يكون فهمه أسهل الآن (ما زال طويلاً جدًا).

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

@ markus2330 سأضع هذا هنا على الرغم من أن المناقشة السابقة كانت في # 3223 ، لأنني أعتقد أنها مناسبة بشكل أفضل.

لقد اكتشفت / تذكرت للتو أنه في الإصدار الحالي من Elektra [1] ، هناك بالفعل (ونفذ بهذه الطريقة) أن "أي جزء من اسم مفتاح ESCAPED يبدأ بـ @ يجعل المفتاح بأكمله غير صالح". هذا يعني أنه يمكننا - بدون تنفيذ أي من التغييرات الأخرى من الاقتراح - استخدام أسماء الحقول التي تبدأ بـ @ لأغراض خاصة في مكونات التخزين الإضافية ، كما يقترح الاقتراح بـ $meta و $value .

@ bauhaus93 قد يساعدك هذا عند التنفيذ والبيانات الوصفية في toml (وأيضًا لمفاتيح القيمة غير الورقية ، إلى حد ما).

بالنسبة لأولئك الذين لم يقرأوا الاقتراح ، ستكون الفكرة أساسًا (لـ JSON):

{
   "key": {
        "@value": "127.0.0.1",
        "sub": "xyz",
        "@meta": {
            "check/ipaddr": "ipv4"
      }
}

يتحول إلى مفتاحين:

key = 127.0.0.1
key/sub = xyz

و key يحتوي أيضًا على هذه البيانات الوصفية:

check/ipaddr = ipv4

~ نظرًا لأن كلا من key/@value و key/@meta هما من أسماء المفاتيح المحجوزة (أو حتى غير صالحين في # 3447) ، فلا يمكن أن يتسبب هذا في أي تعارض.

[1] يذكر master هذا فقط في الوثائق ، لكنه يتيح لك إنشاء مثل هذه المفاتيح. # 3447 من ناحية أخرى ~ يحظر هذه المفاتيح تمامًا ~ يتطلب هروب @ في بداية أجزاء اسم المفتاح في أسماء المفاتيح التي تم تجاوزها. تحتوي الوثائق أيضًا على شرط مماثل لـ _ ، لكن هذا لم يتم تطبيقه في # 3447 أيضًا.

آسف للارتباك ، ولكن كان علي توضيح أجزاء من التعليق أعلاه. الجزء المتعلق بـ @ ينطبق فقط على اسم المفتاح الذي تم تجاوزه. الاسم الذي لم يتم تجاوزه (كسلسلة C) "\01\00key\00@meta\00" لا يزال صالحًا في # 3447 ، كما كان من قبل. هذا يعني أنه لا يمكن استخدام @meta للبيانات الوصفية دون اعتبارات أخرى في المكوّن الإضافي للتخزين.

ومع ذلك ، نظرًا لأنه كان دائمًا اسمًا محجوزًا وسنطلب الهروب في # 3447 ، أعتقد أنه لا يزال من العدل استخدامه في مكون إضافي للتخزين. يجب ألا يتوقع مستخدم IMO أنه يمكن دائمًا استخدام اسم محجوز دون مشاكل. لكن بالطبع سنحتاج إلى اتخاذ بعض الاحتياطات. أحد الاحتمالات هو هذا (JSON مرة أخرى):

{
   "key": {
        "@value": "127.0.0.1",
        "@sub": "xyz",
        "@meta": {
            "check/ipaddr": "ipv4"
      }
}

يتحول إلى مفتاحين (لاحظ \ للهروب):

key = 127.0.0.1
key/\<strong i="15">@sub</strong> = xyz

لكن هذا

{
   "key": {
        "@@value": "127.0.0.1",
        "@@sub": "xyz",
        "@@@sub": "abc",
        "@@meta": {
            "check/ipaddr": "ipv4"
      }
}

يتحول إلى (مرة أخرى \ للهروب):

key/\<strong i="23">@value</strong> = 127.0.0.1
key/\<strong i="24">@sub</strong> = xyz
key/\@<strong i="25">@sub</strong> = abc
key/\@meta/check\/ipaddr = ipv4

القواعد هنا ستكون:

• لا يبدأ اسم الحقل بـ @ -> استخدم اسم الحقل وأضفه بـ keyAddBaseName
• يبدأ اسم الحقل بأكثر من @ -> قم بإزالة أول @ واستخدم الباقي مقابل keyAddBaseName
• يبدأ اسم الحقل بـ @ -> تحقق مما إذا كان لاسم الحقل معنى خاصًا (على سبيل المثال ، @value أو @meta ):
  
  
  
  • إذا كان لها معنى خاص ، فقم بإجراء العملية وفقًا لذلك
  
  
  • وإلا ، فما عليك سوى استخدام اسم الحقل لـ keyAddBaseName (على سبيل المثال ، @sub )
  
  

(ملاحظة: يأخذ keyAddBaseName اسمًا لم يتم تجاوزه ويقوم بعملية الهروب المطلوبة للحفاظ على صحة اسم المفتاح)

لا أفهم الهدف من التعليقين الأخيرين ، هل هذا اقتراح حول استبدال ملحق directoryvalue؟

(لاحظ \ للهروب)

بالنسبة إلى @ عادة ما نستخدم @ للهروب ، لذلك ببساطة لتجاهل أول @ إذا كان هناك عدة. سيكون جيدًا إذا تم توثيق ذلك أيضًا في وصف اسم المفتاح. يمكننا التغيير إلى \ (إذا كان هذا يجعل الهروب لأسماء المفاتيح بشكل عام أسهل للفهم) ولكن هذا يحتاج إلى تغييرات على الأقل في المكون الإضافي base64. (يتم حذف المكون الإضافي null في # 3491)

لا أفهم الهدف من التعليقين الأخيرين ، هل هذا اقتراح حول استبدال ملحق directoryvalue؟

الجزء @value هو نعم. لكنها أكثر عمومية. @meta لتخزين البيانات الوصفية داخل تنسيق بهيكل كائن متداخل واحد ، مثل JSON أو TOML (ما زلت غير متأكد من YAML ، لأن العلامات).
بشكل أساسي ، نظرًا لأن كل شيء في ملف JSON يشير إلى مفتاح ما في مكان ما ، فلا يوجد مكان لتخزين البيانات الوصفية. ما لم تفرض بعض القيود على بنية ملف JSON ، ولكن ربما لا يمكنك فقط تحميل بعض ملفات التكوين. [1]

كما قلت ، تحتاج إلى فرض قيود لتناسب البيانات الوصفية في JSON (AFAIK ينطبق الأمر نفسه على TOML). لذا ، نعم ، اقتراحي في التعليقات أعلاه يفرض قيودًا على ملفات JSON ، لكن التطبيقات التي تستخدم @ في بداية حقل JSON ربما تكون نادرة جدًا.

بالنسبة إلى @ ، عادةً ما نستخدم @ للهروب ، لذلك ببساطة لتجاهل أول @ إذا كان هناك العديد منها. سيكون جيدًا إذا تم توثيق ذلك أيضًا في وصف اسم المفتاح. يمكننا التغيير إلى \ (إذا كان هذا يجعل الهروب لأسماء المفاتيح بشكل عام أسهل للفهم) ولكن هذا يحتاج إلى تغييرات على الأقل في المكون الإضافي base64.

لست متأكدًا من مدى ملاءمة المكوّن الإضافي base64 هنا ، لكن أود أن أكون واضحًا جدًا:

في master (6a1535c094c7be2f441bd0e7b0dda1c50e97ee1d) يعمل keyNew ("/elektra/@abc", KEY_END) وينشئ اسمًا بدون إلغاء مع الأجزاء elektra و @abc .
في # 3447 keyNew ("/elektra/@abc", KEY_END) تُرجع NULL لأن الاسم يعتبر غير صالح ، لكن keyNew ("/elektra/\@abc", KEY_END) يعمل وينشئ اسمًا غير مُلغى مع الأجزاء elektra و @abc .
لست متأكدًا مما يفعله keyNew ("/elektra/\@abc", KEY_END) على المستوى الرئيسي.

keyAddBaseName (k, "@abc") يعمل في كلتا الحالتين ، والفرق الوحيد هو الاسم الذي تم حذفه.

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

[1] كما هو الحال دائمًا ، تكمن المشكلة هنا في أن شركة Elektra تريد أن تفعل كل شيء وترضي الجميع. من ناحية ، نريد السماح بإضافات التخزين التي يمكنها قراءة الملفات العشوائية بتنسيق قياسي (مثل JSON) وتحويلها إلى مجموعات مفاتيح. من ناحية أخرى ، نريد السماح للتطبيقات باستخدام سلاسل عشوائية كجزء من اسم مفتاح. قد يعمل هذا لبعض الوقت ، ولكن على الأقل عندما تصل إلى البيانات الوصفية فإنها تتعطل لبعض التنسيقات.

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

كما قلت ، تحتاج إلى فرض قيود لتناسب البيانات الوصفية

kodebach هل هذا يعني أنك تفضل تقييد التنسيقات التي يمكن تخزين البيانات الوصفية فيها؟

لم أتعثر أبدًا في هذا الأمر ، لأنني استخدمت في الغالب تفريغًا ثم mapstorage ونادرًا ما يتم استيراد / تصدير التكوينات باستخدام مكونات إضافية. هذا مؤسف جدا. كمستخدم ، أفضل أن أكون قادرًا على الاستيراد / التصدير إلى المواصفات القياسية (فقدان البيانات الوصفية) أثناء تخزين البيانات الحقيقية (بما في ذلك البيانات الوصفية) باستخدام تنسيق elektra الداخلي التعسفي.

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

@ markus2330 ما رأيك في فرض قيود على الشكل؟

تحرير: أوافق على أن "إلكترا تريد أن تفعل كل شيء وإرضاء الجميع" يمثل مشكلة.

هل هذا يعني أنك تفضل تقييد التنسيقات التي يمكن تخزين البيانات الوصفية فيها؟

نحن بحاجة إلى تحديد أولوياتنا. ما هو بالضبط ضرورة مطلقة ، وأين يمكن أن تتغير الأشياء. كما هو الحال الآن ، فإن الطريقة الوحيدة للعديد من التنسيقات هي تخزين البيانات الوصفية في التعليقات ( @ bauhaus93 فعل ذلك في # 3500 لـ TOML). IMO هذا ليس حلاً ، ولكنه مجرد عمل ثقيل. أسوأ جزء هو أنه يسيء استخدام الجزء الوحيد الذي لا ينبغي أبدًا لمسه بواسطة المحلل اللغوي ويمكن أن يؤثر بشكل كبير على قابلية قراءة ملف التخزين. بعض التنسيقات (وهي JSON) أيضًا لا تحتوي على تعليقات.

القيود الأساسية للغاية التي يمكننا فرضها (باستخدام JSON كمثال مرة أخرى) ستكون أن جميع الملفات يجب أن تبدو على النحو التالي:

{
    "kdb": {
       "elektra": {
          "version": 1
        }
    },
    "meta": {
       "elektra/version": {
           "type": "long"
       }
    }
}

تشمل "القيود" الأخرى تفسير أسماء مفاتيح معينة مثل @meta بطرق خاصة وتوفير طرق للهروب.

يحتوي الكائن kdb على المفاتيح الفعلية و meta يحتوي على البيانات الوصفية. (ملاحظة: لحل المفاتيح غير الطرفية بالقيم ، ستحتاج إلى كائن آخر)

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

كمستخدم ، أفضل أن أكون قادرًا على الاستيراد / التصدير إلى المواصفات القياسية (فقدان البيانات الوصفية) أثناء تخزين البيانات الحقيقية (بما في ذلك البيانات الوصفية) باستخدام تنسيق elektra الداخلي التعسفي.

أوافق ، لكن استيراد / تصدير كل شيء يتعارض قليلاً مع فكرة نقطة التثبيت في Elektra.

أعلم بالفعل ، لا أحد يريد تنفيذ ذلك ، ولكن هناك حل عام للغاية:

إذا كانت نقطة التحميل تستخدم مكونًا إضافيًا للتخزين لا يدعم جميع ميزات Elektra ، فإن المكون الإضافي الخلفي ينشئ ملف تخزين احتياطي ثانوي بتنسيق يدعم جميع الميزات (على سبيل المثال ، quickdump ، mmapstorage يبدو وكأنه مضيعة لمساحة القرص هنا). عند كتابة نقطة وصل ، نكتب ببساطة باستخدام كلا المكونين الإضافيين. عند القراءة ، نقرأ أولاً الملف الاحتياطي الثانوي ثم الملف الأساسي. قد يتطلب هذا عملية دمج ، لكننا سنأخذ الملف الأساسي كمصدر من خلال حتى يكون الدمج بسيطًا للغاية.

أعتقد أن تقييد التنسيق قد يكون مربكًا للمستخدمين.

قطعا. لكن من الواضح لي أن Elektra حاليًا تسمح بالكثير ويجب تقييد شيء ما.

حتى الحل مع ملفات متعددة يتطلب نوعًا من القيود على أسماء ملفات التكوين لتجنب الاصطدامات.

في الأصل اعتقدت أن الحل الأسهل هو تقييد أسماء مفاتيح Elektra ، لأن هذا هو الجزء الذي نتمتع بسلطة أكبر عليه. ولكن من الواضح أن هناك تطبيقات تستخدم معرّفات WiFi SSID [1] مباشرةً كجزء من اسم المفتاح ، لذا لا يعمل ذلك. على الأقل ليس بدون جهد كبير ، كما أظهر اقتراحي ...
IMO سيظل الحل الأفضل لكل هذا أن تقول فقط "أجزاء اسم المفتاح ليست تسلسلات عشوائية من البايت غير الصفري بعد الآن " وأن يتم ذلك. للمقارنة ، يسمح POSIX فقط بالأحرف التالية في أسماء الملفات:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

ويبدو أن هذا كافٍ للناس. جميع أنظمة الملفات المدرجة في ويكيبيديا (باستثناء تلك التي لا تحتوي على أدلة) لديها نوع من القيود على أسماء الملفات.

أريد أن أؤكد مرة أخرى: كل هذا يتلخص في حقيقة أننا اتخذنا "أجزاء اسم المفتاح هي تسلسلات عشوائية من البايت غير الصفرية" كبديهية [2]. سيكون تغيير هذا أمرًا سهلاً وسيصلح كل شيء. حتى انها قد تكون صغيرة قيود على سبيل المثال "مفتاح اسم أجزاء هي تسلسل التعسفي من غير صفر بايت، باستثناء تلك التي على حد سواء بداية مع @$% وتنتهي في !%& في نفس الوقت".
مجرد حجز جزء اسم مفتاح واحد ، مثل "أجزاء اسم المفتاح هي تسلسلات عشوائية من بايت غير صفري ، باستثناء !@& ليست كذلك" ، من شأنه أن يمنحنا الكثير من الاحتمالات. هيك ، حتى التقييد "الجزء الأخير من اسم المفتاح في اسم المفتاح يجب ألا ينتهي بـ @%& " يجب أن يكون كافياً. أي نوع من القيود [3] بغض النظر عن مدى صغره سوف يمنحنا مساحة لتنفيذ كل أنواع الأشياء.
بالطبع ، العديد من القيود تجعل الحلول ممكنة ، لكن الحل الجيد والقابل للاستخدام قد يتطلب قيودًا أكبر.

عذرًا ، إذا كان هذا يبدو وكأنه صراخ ، ولكن في مرحلة ما ، يصبح الأمر محبطًا حقًا أن الجميع يوافق على وجود مشكلة ، لكن كل حل يعتبر به عيب أو يُنظر إليه على أنه معقد للغاية.

[1] وفقًا لـ Wikipedia حتى 802.11-2012 ، كان طول WiFi SSID "من صفر إلى 32 ثماني بت (32 بايت)" بما في ذلك صفر بايت و "يجب أن تكون حزم الشبكة اللاسلكية جاهزة للتعامل مع القيم العشوائية في حقل SSID" ، حتى على الرغم من أن SSIDs يجب أن تكون الآن صالحة UTF-8. حتى مجرد keyAddBaseName سوف جي وواي فاي SSID دون أي منطق إضافية لا تكون متوافقة مع المعايير على أي حال.

[2] لهذا السبب في الواقع ، بدأت الوثائق الجديدة في # 3447 بأجزاء اسم المفتاح. من الأسهل (والأكثر منطقية في IMO) شرح أسماء المفاتيح الحالية بالبدء بأجزاء Key Name والانتقال من هناك. لكن الطريقة القديمة

خذ مسار نظام ملفات Unix / POSIX وأضف مساحة اسم ، ولكن يوجد أيضًا هذا الشيء الخاص مثل الأجزاء الفارغة وهناك تسلسلات هروب ، ثم هناك الإصدار الذي لم يتم تجاوزه - إنه شبه مخفي ولكن ربما يجب استخدامه لكل شيء بخلاف الطباعة - أوه والمصفوفات شيء ، كما أن بعض الأجزاء محجوزة ولكنها غير محجوزة فعليًا ، لذلك لا نستخدمها في الواقع لأي شيء منخفض المستوى ، ....

يظهر أفضل كثيرا كيف بجنون أسماء مفتاح معقدة ومعقدة هي.

[3] في حال كنت تتساءل ، فإن نعم # 3447 يفرض بعض القيود الجديدة ، ولكن هذه القيود غير مجدية ، لأنها لا تؤثر على اسم المفتاح الذي لم يتم تجاوزه (باستثناء مساحة الاسم) بأي شكل من الأشكال.

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

ناقشنا هذا فيما يتعلق بتنفيذ ذاكرة التخزين المؤقت وقررنا عدم القيام بذلك. يحتوي التنفيذ الحالي لوحدة الحل على ضمانات تناسق أقوى مما يمكن تحقيقه عند استخدام ملفين. يستخدم المحلل الدالة atomic rename() للتأكد من أن العملية إما تقرأ الملف القديم أو الجديد ، ولكنها تقرأ دائمًا عملية متسقة. لسوء الحظ ، لا يمكن (على حد علمي) القيام بذلك مع ملفات متعددة مع وجود نفس الضمانات. سأكون مترددًا في استخدام ملفات متعددة حيث نحتاج إلى ضمان الاتساق.

أوافق ، لكن استيراد / تصدير كل شيء يتعارض قليلاً مع فكرة نقطة التثبيت في Elektra.

صحيح.

كل هذا يتلخص في حقيقة أننا اتخذنا "أجزاء الاسم الرئيسية هي تسلسلات عشوائية من البايت غير الصفرية" كبديهية [2].

أوافق ، هذا هو الجزء الذي تكون فيه القيود منطقية. كما قلت ، أسماء الملفات مقيدة تمامًا ولا تزال تعمل بشكل جيد. ما لم يعرف أي شخص سببًا وجيهًا لعدم تقييد أسماء المفاتيح (ربما @ markus2330)؟

آسف ، إذا كان هذا يبدو وكأنه تشدق

لا ، وشكرا لك على مناقشة هذا. ما لم يعرف @ markus2330 بعض الأسباب التي تجعلنا لا نستطيع تغيير هذا ، فأنا منفتح تمامًا على اقتراحك (مثل تقييد !@& ).

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

هذا سبب وجيه ، مقابل ملفات متعددة نعم ...

أنا منفتح تمامًا على اقتراحك (مثل تقييد !@& ).

بشكل أكثر واقعية ، يمكننا فرض التقييد: " يجب ألا يحتوي اسم المفتاح على جزء اسم المفتاح @elektra " (ربما تكون بادئة أكثر غموضًا ، إذا كان ذلك يساعد). أعتقد أن استخدام elektra قد يجعل الأمر برمته أكثر منطقية للمستخدمين.

شخصيا، أعتقد أننا يجب أن يترك مجالا للمستقبل، ولكن إذا تقيد جميع أسماء مفتاح كبير جدا، ونحن يمكن أن تقيد أيضا ما kdbGet يمكن العودة وما kdbSet يمكن قبوله. لذا فإن التقييد أعلاه سينطبق فقط على ما هو آخر مكون إضافي أثناء إرجاع kdbGet وعلى KeySet الممنوح لـ kdbSet . في الأساس ، سنقيد فقط المفاتيح التي يمكن تخزينها من وجهة نظر التطبيق. سيكون هذا مشابهًا لما لدينا بالفعل مع system:/elektra (على الرغم من أننا هذه المرة سنفرض التقييد بالفعل).

شكرا جزيلا على هذه المناقشات القيمة لك. لقد بدأت # 3514 لتلخيص القرارات المهمة المنتشرة في كل مكان. من فضلك تفضل التعليق مباشرة على النص في # 3514 ، حتى نتمكن من التوصل إلى استنتاجات.

الجزء value هو نعم. لكنها أكثر عمومية. يمكن استخدام meta لتخزين البيانات الوصفية داخل تنسيق بهيكل كائن متداخل واحد ، مثل JSON أو TOML (ما زلت غير متأكد من YAML ، لأن العلامات).
بشكل أساسي ، نظرًا لأن كل شيء في ملف JSON يشير إلى مفتاح ما في مكان ما ، فلا يوجد مكان لتخزين البيانات الوصفية.

لم أعد أعتقد أنه ينبغي أن يكون هدفنا هو التحايل على قيود تنسيقات الملفات. إذا كان JSON لا يدعم البيانات الوصفية والقيم غير الورقية ، فإن Elektra مع تثبيت ملف JSON ، ببساطة يعيد توجيه قيودها على مجموعات المفاتيح. يمكننا توثيقها ، كما هو مقترح في # 3504 ويجب أن تفشل مكونات التخزين الإضافية في مجموعات المفاتيح هذه ولكن ليس أكثر من ذلك. (بالطبع يمكن لأي شخص أن يبتكر تنسيق ملف JSON فائقًا مع قيود أقل ولكن هذا يتجاوز قوتنا البشرية الحالية وبالتالي فهو غير ذي صلة.)

لكن التطبيقات التي تستخدم @ في بداية حقل JSON نادرة جدًا على الأرجح.

من تعرف؟

يعمل keyAddBaseName (k، "abc") في كلتا الحالتين ، والفرق الوحيد هو الاسم الذي تم تخطيه الذي ينشئه.

يبدو جيدا.

ولكن على الأقل عند الوصول إلى البيانات الوصفية ، فإنها تتعطل لبعض التنسيقات.

نعم ، نحتاج إلى التخلي عن فكرة أن أي تنسيق يمكن أن يدعم أي شيء.

ليس من الواضح بالنسبة لي كيف سيتمكن المستخدم من التحقق من أن ملفات التكوين الخاصة به تتوافق مع المواصفات المقيدة.

أعتقد أن معظم التطبيقات لن تكون متطلبة للغاية على أي حال (على سبيل المثال ، تحتوي فقط على قيم أوراق ولا تحتاج إلى أي بيانات وصفية باستثناء النوع) ، لذلك كل ما نناقشه هنا يتعلق فقط بالتطبيقات الاستثنائية. بالنسبة لهذه التطبيقات ، أعتقد أنه من الأفضل أن يطور مطورو التطبيقات مكونات التخزين الإضافية الخاصة بهم أو يستخدمون أفضل مكونات التخزين الإضافية لدينا ، والتي تدعم مثل هذه الأشياء.

@ markus2330 ما رأيك في فرض قيود على الشكل؟

انها ليست فكرة جيدة. يجب أن ندعم تنسيقات ملفات التكوين كمعيار. يمكن أن تكون مشكلة كبيرة إذا تم رفض بعض ملفات JSON / XML الصالحة بواسطة Elektra. لكن من ناحية أخرى ، لا نحتاج إلى دعم أي شيء أكثر من التوحيد القياسي. لمحاولة هذا كان خطأ من الماضي (محاولة إرضاء أي شخص).

نحن بحاجة إلى تحديد أولوياتنا. ما هو بالضبط ضرورة مطلقة ، وأين يمكن أن تتغير الأشياء.

doc / GOALS.md في # 3514

أسوأ جزء هو أنه يسيء استخدام الجزء الوحيد الذي لا ينبغي أبدًا لمسه بواسطة المحلل اللغوي ويمكن أن يؤثر بشكل كبير على قابلية قراءة ملف التخزين.

أوافق على أنها ليست أفضل فكرة ، فقد واجهت بالفعل الكثير من المشكلات في المكون الإضافي ini . badcec5407df6947a67750afd8f0946245c5a5bb

بدلاً من كائنين JSON ، يمكننا أيضًا استخدام ملفات منفصلة.

انظر أدناه.

للمقارنة ، يسمح POSIX فقط بالأحرف التالية في أسماء الملفات:

هذه هي "مجموعة أحرف اسم الملف المحمول" وأشك في وجود أي نظام ملفات قيد الاستخدام والذي يدعم هذا فقط. في تجربتي ، فإن أي تفسير لأسماء الملفات يستدعي المشاكل فقط (على سبيل المثال ، كان لدى JFS مثل هذه الميزات).

ويبدو أن هذا كافٍ للناس.

بالنسبة لمصدر Elektra ، فهو تقريبًا # 1615: غمزة:

لكن التطبيقات الحقيقية أرادت على الفور المزيد ... (على سبيل المثال ، المسافات ، علامات التشكيل ، ....)

سيكون تغيير هذا أمرًا سهلاً وسيصلح كل شيء.

الأمر ليس بهذه البساطة: فهو يجعل ملحقات التخزين أكثر تعقيدًا. إنه ببساطة ينقل المنطق إلى أماكن أخرى.

باستثناء تلك التي تبدأ بـ @ $٪ وتنتهي بـ!٪ وفي نفس الوقت

هذه الفكرة مشابهة لـ CDATA . إنه ليس حلاً جميلًا وغير مفيد في الممارسة.

مستندات HERE أفضل قليلاً ، حيث يمكن للمستخدم تحديد تسلسل الهروب.

ولكن ما الميزة التي تعتقد أننا بحاجة إليها بالضبط؟ أعتقد أنه يجب علينا بدلاً من ذلك نسيان هذه الميزات واستخدام البيانات الوصفية بشكل صحيح لإعطاء دلالات للمفاتيح.

عذرًا ، إذا كان هذا يبدو وكأنه صراخ ، ولكن في مرحلة ما ، يصبح الأمر محبطًا حقًا أن الجميع يوافق على وجود مشكلة ، لكن كل حل يعتبر به عيب أو يُنظر إليه على أنه معقد للغاية.

نقطتي هي: ربما لا نحتاج إلى حل لأن المشكلة غير موجودة.

يجب أن يكون الآن صالحًا لـ UTF-8

هل لا يزال بإمكانهم الاحتفاظ بأحرف فارغة؟ بالمناسبة. توصلت إلى مثال SSID لأن هذا كان مطلبًا حقيقيًا لعميل حقيقي (برودكوم). لم تكن الأحرف الفارغة مطلوبة ، فمن الواضح أن char* بدون حجم لا يمكن أن يدعم هذا ، لذلك لم نناقش هذا حتى.

يُظهر بشكل أفضل مدى تعقيد وتعقيد الأسماء الرئيسية بجنون.

نعم ، لكنهم أفضل من أن يكون لديهم مثل هذا المنطق في كل تطبيق ومكوِّن إضافي للتخزين.

في حال كنت تتساءل ، نعم # 3447 يفرض بعض القيود الجديدة

نعم ، يمكن أن يكون لاسم المفتاح أي قيود. كان هناك دائمًا قيود على الهروب المتدلي ، لذلك لا يهم المزيد من القيود. # 3447 سيكون تحسينًا كبيرًا لشركة Elektra.

لسوء الحظ ، لا يمكن القيام بذلك (على حد علمي) مع ملفات متعددة مع وجود نفس الضمانات

يمكن القيام بذلك عن طريق كتابة سجل دفتر يومية حيث تكتب فيه كل ما تخطط للقيام به وفي حالة حدوث أي مشاكل يمكنك التعافي من خلال إعادة تشغيل المجلة. إن تنفيذ هذا هو أمر يفوق كثيرا قوة البشر. كما أنه لا يناسب نظام التكوين (ولا أنظمة الملفات) ، فهو أسلوب لقواعد البيانات المنظمة.

لقد جعلته ليس هدفًا في multi_file_backends.md 59066aa99bae707d0f0178841513fd3b8590b5bc

في الأساس ، سنقيد فقط المفاتيح التي يمكن تخزينها من وجهة نظر التطبيق. سيكون هذا مشابهًا لما لدينا بالفعل مع النظام: / elektra (على الرغم من أننا سنفرض التقييد هذه المرة).

يمكننا فرض تقييد system:/elektra . ولكن لماذا تريد تقييد التطبيقات التي يتم تخزينها في الجزء الخاص بها من التسلسل الهرمي؟

أعتقد أنه من الأفضل أن يطور مطورو التطبيقات ملحقات التخزين الخاصة بهم

وبالتالي ، فإنه يتغلب على إحدى الفوائد الرئيسية لـ Elektra: "يقرر المشرف / المستخدم تنسيق التكوين وليس مطور التطبيق".

يمكن أن تكون مشكلة كبيرة إذا تم رفض بعض ملفات JSON / XML الصالحة بواسطة Elektra

لم يكن هذا اقتراحي أبدا. بالطبع يجب أن نقبل كل JSON صالح. السؤال هو ما الذي ننتجه KeySet . إذا استخدمنا "@value" للقيم غير الطرفية كما هو مقترح أعلاه ، فلا يزال بإمكاننا قبول كل JSON صالح. الناتج KeySet سيكون له هيكل مختلف قليلاً في بعض الأحيان.

للمقارنة ، يسمح POSIX فقط بالأحرف التالية في أسماء الملفات:

هذه هي "مجموعة أحرف اسم الملف المحمول" وأشك في وجود أي نظام ملفات قيد الاستخدام والذي يدعم هذا فقط. في تجربتي ، فإن أي تفسير لأسماء الملفات يستدعي المشاكل فقط (على سبيل المثال ، كان لدى JFS مثل هذه الميزات).

ويبدو أن هذا كافٍ للناس.

بالنسبة لمصدر Elektra ، فهو تقريبًا # 1615

لكن التطبيقات الحقيقية أرادت على الفور المزيد ... (على سبيل المثال ، المسافات ، علامات التشكيل ، ....)

ما زالوا لا يسمحون بـ / أو الأسماء الفارغة. تحتوي معظمها أيضًا على أطوال قصوى لأسماء الملفات والمسارات. النقطة المهمة هي أن التطبيقات تجد طرقًا للتغلب على القيود. وفي حالتنا يمكننا حتى مساعدتهم في المكتبات.

الأمر ليس بهذه البساطة: فهو يجعل ملحقات التخزين أكثر تعقيدًا. إنه ببساطة ينقل المنطق إلى أماكن أخرى.

انا لا اوافق. تعد مكونات التخزين الإضافية بالفعل معقدة للغاية ، نسبيًا لن يكون هذا سوى إزعاج بسيط. (بافتراض أننا نقدم مكتبة جيدة storage مع وظائف مساعدة)

هذه الفكرة مشابهة لـ CDATA. إنه ليس حلاً جميلًا وغير مفيد في الممارسة.

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

تحتاج كل من المستندات CDATA و HERE إلى حجز بعض البنية ، من وجهة نظر Elektra الحالية لا يوجد فرق. كلا الإصدارين عبارة عن قيود على أسماء المفاتيح.

كما أن كلاهما أقوى بكثير مما اقترحته. اقتراحي سوف "يتخطى" جزء اسم المفتاح الكامل في المرة الواحدة.

أعتقد أنه يجب علينا بدلاً من ذلك نسيان هذه الميزات واستخدام البيانات الوصفية بشكل صحيح لإعطاء دلالات للمفاتيح.

لقد قلت للتو ، أن بعض مكونات التخزين الإضافية قد لا تدعم البيانات الوصفية. لذلك يبدو أن هذا ليس خيارًا.

نقطتي هي: ربما لا نحتاج إلى حل لأن المشكلة غير موجودة.

بالطبع ، إذا غيرت رأيك فقط وقلت إن تنسيق التخزين يمكن أن يحد من قدرات Elektra ، فستختفي المشكلة. لكن هذا يغير بشكل أساسي وعد Elektra للمستخدمين. سنقيد جميع المستخدمين فقط للسماح لبعض المطورين بتأمين بضعة أسطر من التعليمات البرمجية التي تتعامل مع ترميز القيم الخاصة.

هل لا يزال بإمكانهم الاحتفاظ بأحرف فارغة؟

من المحتمل أن NUL هو حرف UTF-8 صالح.

بدون حجم لا يمكن أن تدعم هذا

حسنًا ، الحد الأقصى لحجم SSID هو 32 بايت ، لذلك لا يتعين عليك تمرير الحجم المحيطي ، طالما أن المخزن المؤقت دائمًا 32 بايت وغير مبطن.

نعم ، يمكن أن يكون لاسم المفتاح أي قيود.

يرجى تجعل عقلك. لقد جادلت طوال هذا الوقت بأنه لا يمكن أن تكون هناك أية قيود.

كان هناك دائمًا قيود على الهروب المتدلي ، لذلك لا يهم المزيد من القيود.

"الهروب المتدلي" ليس قيدًا. إنه خطأ نحوي في اسم المفتاح الذي تم تجاوزه. أسماء المفاتيح التي تم هروبها لم تكن أبدًا سلاسل عشوائية. هذا شيء مختلف تماما

يمكننا فرض تقييد system:/elektra .

قد نطلب علامة في keyNew للسماح بمثل هذه الأسماء. وإلا فإن التطبيق الذي يقبل أسماء المفاتيح من المستخدم ، سيتعين عليه تعقيم الإدخال. راجع أيضًا مشكلة kdb import في # 3299.

ولكن لماذا تريد تقييد التطبيقات التي يتم تخزينها في الجزء الخاص بها من التسلسل الهرمي؟

لا أريد تقييد _ ما_ التطبيقات المخزنة ، ولكن _كيف _ يخزنونها. هذا يمنح الإضافات (التخزين) المزيد من الحرية.

وبالتالي ، فإنه يتغلب على إحدى الفوائد الرئيسية لـ Elektra: "يقرر المشرف / المستخدم تنسيق التكوين وليس مطور التطبيق".

لم يكن من الممكن أبدًا استخدام أي مكون إضافي للتخزين لأي تطبيق. هذا لا يعني أننا نسحب صلاحية المشرف / المستخدم لتغيير نقاط التحميل. لكننا نحتاج إلى أن نكون صادقين وأن نقدم إخلاءًا كبيرًا من المسؤولية بأن القيام بذلك ينطوي على بعض المخاطر.

لم يكن هذا اقتراحي أبدا. بالطبع يجب أن نقبل كل JSON صالح. السؤال هو ما الذي ننتجه KeySet. إذا استخدمنا "value" للقيم غير الطرفية على النحو المقترح أعلاه ، فلا يزال بإمكاننا قبول كل JSON صالح. سيكون لمجموعة المفاتيح الناتجة بنية مختلفة قليلاً في بعض الأحيان.

في هذه المشكلة ، أضعنا بالفعل ساعات طويلة للغاية في حوالي 10 سنوات ، دون أي تقدم. كانت الفكرة الأولى هي Keytometa ، ثم directoryvalue ، مع العديد من الخطوات بينهما. لماذا لا تقبل JSON كما هي؟ ستعمل مع معظم التطبيقات. هل الهيكل الأفضل قليلاً يستحق ذلك؟

النقطة المهمة هي أن التطبيقات تجد طرقًا للتغلب على القيود.

حتى أن التطبيقات تجد طرقًا للتغلب على عدم وجود مكتبة تكوين. لماذا يستخدمون مكتبة التكوين التي تمنحهم قيودًا ليست لديهم حاليًا؟ من السهل جدًا تنفيذ ملف خاصية يسمح بأي أسماء مفاتيح بأي قيم. لماذا قد تكون إليكترا ذات فائدة إذا لم تقدم هذا حتى؟

وفي حالتنا يمكننا حتى مساعدتهم في المكتبات.

نحتاج أولاً إلى توضيح الأهداف قبل أن نتوصل إلى حلول معقدة.

انا لا اوافق. مكونات التخزين الإضافية معقدة للغاية بالفعل ،

هل نظرت إلى Simpleini أو ni أو c أو mini؟ لا يزال بإمكانك كتابة مكون إضافي مفيد للتخزين بسهولة في أقل من يوم.

نسبيًا ، لن يكون هذا سوى إزعاج بسيط. (بافتراض أننا نقدم مكتبة تخزين جيدة بوظائف مساعدة)

للأسف الافتراض لا يصمد. لقد حاولنا أيضًا إنشاء مكتبات مساعدة منذ سنوات عديدة ، ولكن دون نجاح يذكر. ما يتم عمله في الجوهر بشكل صحيح كان دائمًا الحل الأفضل.

تحتاج كل من مستندات CDATA و HERE إلى الاحتفاظ ببعض بناء الجملة ، من وجهة نظر Elektra الحالية ، لا يوجد فرق. كلا الإصدارين عبارة عن قيود على أسماء المفاتيح.

لا ، لا تحتفظ مستندات HERE بأي بنية. يمكنك أن تقرر سريعًا (على سبيل المثال بناءً على البيانات) الكلمة الأساسية التي تريد استخدامها لتمييز نهاية المستند.

أعتقد أنه يجب علينا بدلاً من ذلك نسيان هذه الميزات واستخدام البيانات الوصفية بشكل صحيح لإعطاء دلالات للمفاتيح.
لقد قلت للتو ، أن بعض مكونات التخزين الإضافية قد لا تدعم البيانات الوصفية. لذلك يبدو أن هذا ليس خيارًا.

الطريقة الصحيحة هي تحديد المفاتيح في مساحة الاسم spec . لا تحتاج مكونات التخزين الإضافية في مساحات الأسماء الأخرى إلى تخزين أي بيانات وصفية. انظر قرار التعسفي في metadata.md # 3514

بالطبع ، إذا غيرت رأيك فقط وقلت إن تنسيق التخزين يمكن أن يحد من قدرات Elektra ، فستختفي المشكلة. لكن هذا يغير بشكل أساسي وعد Elektra للمستخدمين. سنقيد جميع المستخدمين فقط للسماح لبعض المطورين بتأمين بضعة أسطر من التعليمات البرمجية التي تتعامل مع ترميز القيم الخاصة.

لقد فصلت هذا السؤال إلى # 3515

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

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

يمكننا فرض قيود النظام: / elektra.
قد نطلب علامة في keyNew للسماح لمثل هذه الأسماء. وإلا فإن التطبيق الذي يقبل أسماء المفاتيح من المستخدم ، سيتعين عليه تعقيم الإدخال.

كنت أفكر في مكون إضافي يرفض أي شيء مكتوب على /elektra والذي لا يؤكد الأدوات المسموح لها بالكتابة هناك. أعتقد أنها ذات أولوية منخفضة.

لا ، لا تحتفظ مستندات HERE بأي بنية. يمكنك أن تقرر سريعًا (على سبيل المثال بناءً على البيانات) الكلمة الأساسية التي تريد استخدامها لتمييز نهاية المستند.

نعم ، لا يزال يتم حجز << لبدء مستندات HERE. علامة النهاية محددة من قبل المستخدم ، لكن من الواضح أن البداية لا يمكن أن تكون كذلك.
على أي حال ، هذا ليس مهما.

لم يكن من الممكن أبدًا استخدام أي مكون إضافي للتخزين لأي تطبيق.

لا بأس بالنسبة لي ، إذا لم تكن جميع المكونات الإضافية تدعم كل شيء ، ولكن إذا كان أحد التطبيقات يستخدم مكونًا إضافيًا للتخزين المخصص ، فلن يكون لدى المسؤول / المستخدم أي خيار. يجب أن يكون هناك بعض الخيارات على الأقل ، حتى لو كانت مثل YAML أو TOML. إذا كان التنسيق المخصص المصمم خصيصًا لـ Elektra يدعم كل شيء ، فأنا أخشى ألا يستخدم أحد Elektra. بالنسبة لي ، تتمثل إحدى أهم ميزات Elektra في أنه يمكن للمستخدم / amdin دائمًا استخدام تنسيق التكوين المفضل لديهم بغض النظر عن التطبيق.

هل نظرت إلى Simpleini أو ni أو c أو mini؟ لا يزال بإمكانك كتابة مكون إضافي مفيد للتخزين بسهولة في أقل من يوم.

c للكتابة فقط. لا يدعم mini البيانات الوصفية وتحذف AFAICT جميع التعليقات من الملف. لا يدعم simpleini أيضًا البيانات الوصفية ويسرد الكثير من القيود في README.

بشكل عام ، لا تُعد مكونات INI الإضافية مثالًا جيدًا ، لأن INI ليس لها مواصفات بالفعل ، لذلك لا توجد قيود قادمة من التنسيق.

يعتمد ni على مكتبة موجودة. هذا هو السبب في أن الكود قصير جدًا وبسيط.

لكن ni هو في الواقع مثال جيد جدًا لما أود فعله. يستخدم تفسيرًا محددًا جدًا لملفات INI قد لا يريد مطورو التطبيقات ذلك. هذا في الواقع يثير سؤالا آخر.

ما هي حالة الاستخدام الأكثر أهمية؟

1. تحويل تطبيق موجود إلى Elektra مع الاحتفاظ بملفات التكوين كما هي
2. كتابة تطبيقات جديدة سيعتمد تنسيق تكوينها على ما يناسب نظام Elektra بشكل أفضل

في الحالة الأولى ، نحتاج إلى مكونات إضافية يمكنها قراءة أي ملف وإنتاج ملفات KeySet s مفيدة.
بالنسبة للحالة الثانية ، حتى القيود الشديدة مثل تلك التي يفرضها ni قد لا تكون مشكلة.

الطريقة الصحيحة هي تحديد المفاتيح في مساحة الاسم spec . لا تحتاج مكونات التخزين الإضافية في مساحات الأسماء الأخرى إلى تخزين أي بيانات وصفية.

نعم ، هذا حل ممكن. لكنه يتطلب الكثير من العمل لجعل spec يعمل بشكل صحيح. على أقل تقدير ، نحتاج إلى بعض ضمانات طلب المكونات الإضافية داخل موضع postgetstorage .

ولكنه يسبب بعض الصعوبات في البيانات الوصفية المستنبطة من تنسيق التخزين (على سبيل المثال ، النوع ، الصفيف). هل سيكون خطأ ، إذا قرأنا مصفوفة JSON لا تحتوي على بيانات وصفية مطابقة لـ array في spec ؟

ومع ذلك ، فإن هذا لا يحل مشكلة المفاتيح غير الطرفية ذات القيم.

أسماء المفاتيح الملقب بـ keySetName يمكن أن يكون لها قيود (على سبيل المثال ، فشل لبعض الوسائط) ، أسماء أجزاء المفتاح الملقب keySetBaseName لا يمكن أن يكون لها قيود (لا يفشل أبدًا في أي وسيطة).

هذان شيئان مختلفان تمامًا. يقبل keySetName اسم مفتاح تم تجاوزه ، بينما يقبل keySetBaseName جزءًا من اسم مفتاح لم يتم إلغاؤه . بالطبع هناك قيود على اسم مفتاح تم الهروب منه.

ومع ذلك ، فإن كل شيء حول أسماء مفاتيح Elektra يعتمد على جزء اسم المفتاح _ (انظر أيضًا docu في # 3447). لذا فإن السؤال الوحيد الذي نحتاج إلى مناقشته هو:

_ما هو جزء الاسم الرئيسي؟ _

لا بأس بالنسبة لي ، إذا لم تكن جميع المكونات الإضافية تدعم كل شيء ، ولكن إذا كان أحد التطبيقات يستخدم مكونًا إضافيًا للتخزين المخصص ، فلن يكون لدى المسؤول / المستخدم أي خيار.

لا أفهم كيف سيكون هذا ممكناً. في Elektra ، يمكنك دائمًا تنفيذ البدائل طالما أن هذا البديل ينتج مجموعات مفاتيح مناسبة للتطبيق. الشيء الوحيد الذي تم إصلاحه هو KeySet ولكن كيفية إنتاج KeySet دائمًا شيء قابل للتبديل. بالنسبة لي ، هذه هي الميزة الرئيسية لـ Elektra.

هذا هو السبب في أن KeySet (بما في ذلك أسماء المفاتيح) هي أهم (وأصعب) القرارات على الإطلاق.

يجب أن يكون هناك بعض الخيارات على الأقل ، حتى لو كانت مثل YAML أو TOML. إذا كان التنسيق المخصص المصمم خصيصًا لـ Elektra يدعم كل شيء ، فأنا أخشى ألا يستخدم أحد Elektra. بالنسبة لي ، تتمثل إحدى أهم ميزات Elektra في أنه يمكن للمستخدم / amdin دائمًا استخدام تنسيق التكوين المفضل لديهم بغض النظر عن التطبيق.

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

لا يدعم mini البيانات الوصفية ويقوم AFAICT بحذف جميع التعليقات من الملف. لا يدعم Simpleini أيضًا البيانات الوصفية ويسرد الكثير من القيود في README.

بالنسبة لمعظم التطبيقات ، هذه القيود غير ذات صلة. أداة واحدة أستخدمها تعمل مع simpleini وأيضًا مصغرة كخلفية.

أعتقد أننا وصلنا بالفعل إلى نفس النتيجة تقريبًا: أيًا كان ما يحدث للحصول على KeySet الصحيح ، يجب أن يحدث داخل مكون التخزين الإضافي. يعد استخدام "مكتبة التخزين" مفيدًا بالطبع ولكنه في النهاية تفاصيل تنفيذ. الفكرة القائلة بأن "الإضافات اللاحقة تعمل على إصلاح الأخطاء التي ارتكبها مكون التخزين الإضافي" فشلت. فلماذا نحتاج إلى مزيد من بناء الجملة في اسم المفتاح؟ كل ما هو مطلوب في بناء الجملة يمكن حذفه داخل البرنامج المساعد التخزين.

1. تحويل تطبيق موجود إلى Elektra مع الاحتفاظ بملفات التكوين كما هي
2. كتابة تطبيقات جديدة سيعتمد تنسيق تكوينها على ما يناسب نظام Elektra بشكل أفضل

إيمهو "1." هو أكثر أهمية الآن ، لأننا بحاجة إلى هذا لـ KDE. لذلك نحتاج بطريقة ما إلى Elektra في شكل لا ندمر المكون الإضافي kconfig .

حوالي 2." لا أعرف ما الذي تعنيه عبارة "يناسب الأفضل لإلكترا". ليس لشركة Elektra أي غرض لنفسها ، فالغرض الوحيد منها هو تلبية احتياجات المطورين والمستخدمين والمسؤولين.

ولكنه يسبب بعض الصعوبات في البيانات الوصفية المستنبطة من تنسيق التخزين (على سبيل المثال ، النوع ، الصفيف). هل سيكون خطأ ، إذا قرأنا مصفوفة JSON لا تحتوي على بيانات وصفية مطابقة للصفيف في المواصفات؟

لا ، فقط الطريقة الأخرى هي خطأ: إذا كانت المواصفات تتطلب مصفوفة ولكن لا يوجد شيء.

نعم ، هذا حل ممكن. لكنه يتطلب الكثير من العمل لجعل المواصفات تعمل بشكل صحيح. على أقل تقدير ، نحتاج إلى بعض ضمانات طلب المكونات الإضافية في موضع postgetstorage.

نعم ، أوافق تمامًا. وهناك شيء يجب القيام به باستخدام spec أي حال ، لا يمكننا تركه كما هو.

ومع ذلك ، فإن هذا لا يحل مشكلة المفاتيح غير الطرفية ذات القيم.

لقد جادلت بأن هذا ليس مهمًا على أي حال: stuck_out_tongue_winking_eye:

وأنا أوافق على أنه لن يكون مهمًا لجميع التطبيقات تقريبًا.

ما هو جزء اسم المفتاح؟

هل يمكنك عمل مشكلة تسرد النقاط المفتوحة / غير الواضحة؟ أو أفضل: إضافته إلى # 3514؟

لا بأس بالنسبة لي ، إذا لم تكن جميع المكونات الإضافية تدعم كل شيء ، ولكن إذا كان أحد التطبيقات يستخدم مكونًا إضافيًا للتخزين المخصص ، فلن يكون لدى المسؤول / المستخدم أي خيار.

لا أفهم كيف سيكون هذا ممكناً. في Elektra ، يمكنك دائمًا تنفيذ البدائل طالما أن هذا البديل ينتج مجموعات مفاتيح مناسبة للتطبيق. الشيء الوحيد الذي تم إصلاحه هو KeySet ولكن كيفية إنتاج KeySet دائمًا شيء قابل للتبديل. بالنسبة لي ، هذه هي الميزة الرئيسية لـ Elektra.

هذا هو السبب في أن KeySet (بما في ذلك أسماء المفاتيح) هي أهم (وأصعب) القرارات على الإطلاق.

يجب أن يكون هناك بعض الخيارات على الأقل ، حتى لو كانت مثل YAML أو TOML. إذا كان التنسيق المخصص المصمم خصيصًا لـ Elektra يدعم كل شيء ، فأنا أخشى ألا يستخدم أحد Elektra. بالنسبة لي ، تتمثل إحدى أهم ميزات Elektra في أنه يمكن للمستخدم / amdin دائمًا استخدام تنسيق التكوين المفضل لديهم بغض النظر عن التطبيق.

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

>

كان يجب أن أضيف المزيد من السياق إلى ردي. أعتقد أننا على الصفحة في هذا الصدد. كان تعليقي ردًا على هذا البيان منك:

أعتقد أن معظم التطبيقات لن تكون متطلبة للغاية على أي حال (على سبيل المثال ، تحتوي فقط على قيم أوراق ولا تحتاج إلى أي بيانات وصفية باستثناء النوع) ، لذلك كل ما نناقشه هنا يتعلق فقط بالتطبيقات الاستثنائية. بالنسبة لهذه التطبيقات ، أعتقد أنه من الأفضل أن يطور مطورو التطبيقات مكونات التخزين الإضافية الخاصة بهم أو يستخدمون أفضل مكونات التخزين الإضافية لدينا ، والتي تدعم مثل هذه الأشياء.

على وجه الخصوص الجزء: "أعتقد أنه من الأفضل أن يطور مطورو التطبيقات مكونات التخزين الإضافية الخاصة بهم"

في حين أن هذا سيكون دائمًا خيارًا ، أعتقد أنه يجب ألا يكون أبدًا شيئًا نوصي به أو حتى نقترحه كحل. لن يتماشى استخدام مكون إضافي للتخزين المخصص مع فلسفة Elektra ويجب تجنبه قدر الإمكان. ملاحظة: أعني بـ "المكون الإضافي المخصص للتخزين" مكونًا إضافيًا مصممًا للعمل مع تطبيق معين ولكنه لا يضمن التوافق مع باقي تطبيقات Elektra. سيكون الأمر على ما يرام تمامًا ، إذا أراد شخص ما استخدام تنسيق مخصص وقام بتطوير مكون إضافي مطابق متوافق مع بيئة Elektra القياسية.

أعتقد أننا وصلنا بالفعل إلى نفس النتيجة تقريبًا: أيًا كان ما يحدث للحصول على KeySet الصحيح ، يجب أن يحدث داخل مكون التخزين الإضافي. يعد استخدام "مكتبة التخزين" مفيدًا بالطبع ولكنه في النهاية تفاصيل تنفيذ. الفكرة القائلة بأن "الإضافات اللاحقة تعمل على إصلاح الأخطاء التي ارتكبها مكون التخزين الإضافي" فشلت.

نعم ، هذا هو الأساس. لا يمكن أن يعتمد المكون الإضافي للتخزين على المكونات الإضافية الأخرى (ربما باستثناء القيم الثنائية ومثل هذه الأشياء).

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

ولكنه يسبب بعض الصعوبات في البيانات الوصفية المستنبطة من تنسيق التخزين (على سبيل المثال ، النوع ، الصفيف). هل سيكون خطأ ، إذا قرأنا مصفوفة JSON لا تحتوي على بيانات وصفية مطابقة للصفيف في المواصفات؟

لا ، فقط الطريقة الأخرى هي خطأ: إذا كانت المواصفات تتطلب مصفوفة ولكن لا يوجد شيء.

دعنا نذهب خطوة أبعد. ماذا لو كان لدينا هذا JSON [ "a", "b" ] بدون مواصفات وقمنا بتصديره إلى تنسيق بدون بيانات وصفية وبدون مصفوفات (مثل mini )؟ سيتم فقد المعلومات التي تفيد بأن هذه مصفوفة.

نظرًا لأن هذه حالة متطرفة ، فقد نقول فقط: هذا مؤسف ، لكنه ما هو عليه.

وأنا أوافق على أنه لن يكون مهمًا لجميع التطبيقات تقريبًا.

يمكن قول الشيء نفسه عن استخدام أسماء مفاتيح عشوائية. لن تواجه جميع التطبيقات تقريبًا مشكلة ، إذا لم تتمكن من استخدام /@elektra/ في أسماء مفاتيحها.

هل يمكنك عمل مشكلة تسرد النقاط المفتوحة / غير الواضحة؟ أو أفضل: إضافته إلى # 3514؟

سأضع قائمة في مكان ما ، حتى نتمكن من مناقشتها يوم الاثنين.

سيكون الأمر على ما يرام تمامًا ، إذا أراد شخص ما استخدام تنسيق مخصص وقام بتطوير مكون إضافي مطابق متوافق مع بيئة Elektra القياسية.

كنت أفكر في الواقع على هذا المنوال. لكن نعم ، تتسلل الخصائص بسهولة. على سبيل المثال ، المكوّن الإضافي kconfig ، يمكن أن تكون البيانات الوصفية حرفًا واحدًا فقط ، لذا من الواضح أنها لن تكون متوافقة تمامًا مع بيانات التعريف الخاصة بنا (على الأقل طالما أن المحلل اللغوي لا يعيد رسم هذه الشخصية إلى المعنى الفعلي الذي لا يحدث في الوقت الحالي). في الوقت الحالي ، نقوم ببساطة بتمرير البيانات الوصفية المكونة من حرف واحد من خلال الطبقة الخاصة بنا ، وإذا لزم الأمر ، قم بعمل ما كان سيحدث في مكتبة kconfig لو تم تحليل الملف بشكل مباشر.

mpranj هل [$e] على الأقل موجود كثيرًا.

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

في الوقت الحالي ، أفضل إذا أصلحنا الأشياء التي نعرف بالفعل كيفية إصلاحها.

نظرًا لأن هذه حالة متطرفة ، فقد نقول فقط: هذا مؤسف ، لكنه ما هو عليه.

بالضبط ، إذا كنت تريد "الميزة X" فلا يمكنك الحصول على مكون إضافي بدون هذه الميزة في سلسلة الاستيراد / التصدير. الشيء نفسه مع التعليقات وهلم جرا.

مفاتيح غير طرفية ذات قيم.
يمكن قول الشيء نفسه عن استخدام أسماء مفاتيح عشوائية. لن تواجه جميع التطبيقات تقريبًا مشكلة ، إذا لم تتمكن من استخدام / @ elektra / في أسماء مفاتيحها.

نعم. ولكن هناك أيضًا فرق كبير بين شيء لا يعمل مع بعض المكونات الإضافية وشيء لن يعمل على الإطلاق مع Elektra.

سأضع قائمة في مكان ما ، حتى نتمكن من مناقشتها يوم الاثنين.

: +1:

ولكن هناك أيضًا فرق كبير بين شيء لا يعمل مع بعض المكونات الإضافية وشيء لن يعمل على الإطلاق مع Elektra.

لقد فهمت وجهة نظرك ، ولكن من الناحية الواقعية ، كم مرة لن يكون وجود مفاتيح /@elektra/ الواقع مشكلة؟

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

في الوقت الحالي ، أفضل إذا أصلحنا الأشياء التي نعرف بالفعل كيفية إصلاحها.

كانت الفكرة عبارة عن مكون إضافي يتم تثبيته دائمًا ويقوم ببعض الترميز / فك تشفير أسماء المفاتيح. ثم يجب أن يتعامل المكون الإضافي للتخزين فقط مع KeySet s على سبيل المثال لا تحتوي على مفاتيح /@elektra/ . ولكن بسبب الترميز ، لا يزال بإمكان التطبيق استخدام أي اسم مفتاح. يمكن لمكوِّن التخزين الإضافي استخدام مفاتيح /@elektra/ لغرضه الخاص ، مثل البيانات الوصفية والقيم غير الطرفية.

سيكون التأثير قيودًا صغيرة على ملفات التخزين ، ولكن لا توجد قيود على التطبيقات. لن يتأثر أيضًا تعقيد مكونات التخزين الإضافية ، لأن المكون الإضافي للتخزين لا يحتاج إلى استخدام أي مفاتيح /@elektra/ . فقط تلك الإضافات التي تريد دعم مثل البيانات الوصفية يجب أن تكتب كودًا إضافيًا ، ولكن هذا هو الحال دائمًا.

لقد فهمت وجهة نظرك ، ولكن من الناحية الواقعية كم مرة لن يكون وجود / @ elektra / keys في الواقع مشكلة؟

ربما لا توجد مشكلة على الإطلاق. لكنها ستكون مشكلة الآن بقدر ما ستكون في وقت لاحق. فلماذا نحتفظ به الآن وليس عندما نجد حقًا حالة استخدام تتطلب شيئًا كهذا؟ ثم نعلم أنه ليس مجرد خيال ويمكن اختيار اسم مناسب.

في لغات البرمجة نحن (عادة) نحتفظ فقط بالكلمات الرئيسية عندما نقوم بالفعل بعمل امتدادات نحوية.

على سبيل المثال البيانات الوصفية

بالنسبة إلى البيانات الوصفية على المفاتيح ، تعتبر المواصفات هي الحل الأفضل لأنها تشير إلى جميع مساحات الأسماء. البيانات الوصفية غير المحددة هي في الأساس مفيدة فقط في الحفاظ على التنسيق وما شابه.

لأن المكون الإضافي للتخزين لا يجب أن يستخدم أي / @ elektra / keys

لا يتعلق الأمر بأن المكون الإضافي للتخزين يستخدم أي اسم ، ولكن السؤال هو السلوك إذا واجه <strong i="14">@elektra</strong> = something في ملف.

فلماذا نحتفظ به الآن وليس عندما نجد حقًا حالة استخدام تتطلب شيئًا كهذا؟

لأن هذا تغيير كبير وقبل 1.0 هو الوقت المناسب للقيام بمثل هذه الأشياء. خاصة وأن يتم بالفعل تغيير أسماء المفاتيح.

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

بالنسبة إلى البيانات الوصفية على المفاتيح ، تعتبر المواصفات هي الحل الأفضل لأنها تشير إلى جميع مساحات الأسماء.

سأذكر فقط array . فكر قليلاً في الأشياء الموجودة في # 3514 ثم أخبرني كيف أخزن مصفوفة بشكل صحيح في ملف خصائص Java.

سيكون من الجيد ، إذا تم تخزين البيانات الوصفية فقط في spec:/ (قد يؤدي ذلك أيضًا إلى حل بعض المشاكل مع المكوّن الإضافي spec ) ، لكنه سيتطلب بعض التغييرات الكبيرة جدًا على Elektra لجعلها تعمل بشكل جيد.

السؤال هو السلوك إذا واجه <strong i="17">@elektra</strong> = something في ملف

إذا كان المكون الإضافي يستخدم @elektra لتشفير شيء ما (مثل القيم غير الورقية) فهذا ما يحدث.
وإلا: "خطأ: اسم مفتاح غير قانوني"

سأضع قائمة في مكان ما ، حتى نتمكن من مناقشتها يوم الاثنين.

كما وعدت في https://github.com/ElektraInitiative/libelektra/issues/3223#issuecomment -709389141 ، أضفت الآن # 3517.

أخبرني كيف أخزن المصفوفة بشكل صحيح في ملف خصائص Java.

إنه يعمل فقط مع spec .

ولكن سيتطلب بعض التغييرات الكبيرة جدًا على Elektra لجعلها تعمل بشكل جيد.

هل هناك حاجة لبعض التغييرات التي لم يتم تضمينها بعد في تعقب المشكلة؟ أعتقد أنه من الضروري بالنسبة لـ 1.0 أن تعمل أساسيات المواصفات بشكل جيد على الأقل (وللتخلص من الأشياء التي لا تعمل).

إنه يعمل فقط مع spec .

ولكن كيف؟ أنت بحاجة إلى البيانات الوصفية array في مساحات الأسماء الأخرى لتعرف حجم المصفوفة في الواقع.

هل هناك حاجة لبعض التغييرات التي لم يتم تضمينها بعد في تعقب المشكلة؟ أعتقد أنه من الضروري بالنسبة لـ 1.0 أن تعمل أساسيات المواصفات بشكل جيد على الأقل (وللتخلص من الأشياء التي لا تعمل).

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

أكبر مشكلة هي بالتأكيد وظائف البرنامج المساعد الحالية. لكن هذه ستستغرق الكثير من العمل لإصلاحها. IMO هذا الجزء يحتاج بشكل أساسي إلى إعادة تصميم كاملة.

ولكن كيف؟ أنت بحاجة إلى البيانات الوصفية للصفيف في مساحات الأسماء الأخرى لتعرف حجم المصفوفة في الواقع.

نعم ، ستحتاج المواصفات حقًا إلى فهم دلالات البيانات الوصفية ، مثل المصفوفات. لذلك سيتحقق من جميع مساحات الأسماء كيف تبدو المصفوفة فعليًا ، ثم يضيف البيانات الوصفية المناسبة array .

Elektra معقد للغاية لدرجة أنه يكاد يكون من المستحيل أن يكون السبب وتغطية الاختبار الجيدة على الأقل صعبة.

أوافق ، لذلك اجعل الأمر أكثر بساطة. الآن هي الفرصة المثالية. لقد تعلمنا الكثير عما لا يمكن فعله. لذا دعونا نتخلص من تلك الأشياء.

أكبر مشكلة هي بالتأكيد وظائف البرنامج المساعد الحالية. لكن هذه ستستغرق الكثير من العمل لإصلاحها. IMO هذا الجزء يحتاج بشكل أساسي إلى إعادة تصميم كاملة.

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

لذلك لن يكون لدينا ببساطة أي وظائف إضافية عامة عامة ولكن فقط تلك الخاصة بـ mmap والمواصفات والإشعارات (الوظيفة الوحيدة التي نحتاجها حقًا لـ 1.0). قد تكون المواقف العامة جيدة ، لكن من الواضح أنها تتجاوز قدرتنا على اختبار ذلك. قمت بتعديل القرار في 89b29034e1d505f36d298f01bf0fcfd13aa1af70

مزيد من المناقشات من فضلك في # 3514