Libelektra: Reservierte Zeichen in Schlüsselnamen

Siehe auch # 2698 für die Diskussion, welches Zeichen für das Array verwendet werden soll (Globbing)

Wenn Sie \ auflisten, sollten Sie zunächst auch / auf die Liste setzen. Der Schrägstrich ist eindeutig der prototypisch reservierte Charakter (Charakter mit besonderer Bedeutung) in Elektra.

Zweitens sind "zum Globbing verwendet" und "zum Verweisen auf parentKey, z. B. im Plugin für bedingte Bedingungen" hier keine gültigen Anwendungsfälle. Dies sind keine besonderen Bedeutungen beim Entweichen. Wenn Sie eine spezielle Interpretation verhindern möchten, die später erfolgt (z. B. durch ein Plugin oder eine Bibliothek), müssen Sie entweder wissen, dass diese Interpretation auf dem Namen des Escape-Schlüssels basiert (was schlecht wäre, wie in https: // github beschrieben). com / ElektraInitiative / libelektra / issue / 2698 # issuecomment-554636250), oder Sie müssen sicherstellen, dass der nicht entkoppelte Name nicht speziell interpretiert werden kann.

Nehmen wir als Beispiel # . Unsere Globbing-Bibliothek interpretiert den Schlüsselnamen /a/# als "mit jedem Array-Element im Array /a übereinstimmen". Wenn wir das nicht wollen, aber buchstäblich mit /a/# übereinstimmen wollen, müssen wir eine Art Flucht verwenden. /a/\# kann jedoch nicht funktionieren. Was bewirkt der Backslash beim Aufheben des Schlüsselnamens? Um die spezielle Interpretation der Globbing-Bibliothek zu verhindern, müsste sie während des Ausweichens dort bleiben. Dies verstößt jedoch gegen die Regel (°), dass ein Backslash maskiert werden muss, wenn es sich nicht um ein Escape-Zeichen handelt (es ist kein Escape-Zeichen, wenn es beim Entweichen nicht verschwindet). Wir müssen also /a/\\# , das sich in ⊙a⊙\# auflöst (⊙ anstelle von NUL, Namespace und Terminator weggelassen). Aber in diesem Fall hat # keine besondere Bedeutung für das Entschlüsseln des Schlüsselnamens und muss überhaupt nicht berücksichtigt werden.

Mit anderen Worten, um einen Grund anzugeben, warum ein Charakter entkommen muss (warum er reserviert ist), müssen Sie über _ "Welches Verhalten von elektraKeyNameCanonicalize oder elektraKeyNameUnescape würde das Entkommen verhindern?" _ .

Für die Charaktere, die wir eigentlich "reserviert" machen wollen, müssen wir hier eine Entscheidung treffen. Sind diese Zeichen mit besonderer Bedeutung oder tatsächlich reservierte Zeichen?

In meinen Augen sind Zeichen mit besonderer Bedeutung normale Zeichen, die als solche verwendet werden können, aber in einem bestimmten Kontext eine spezielle Interpretation haben können (z. B. % wenn es sich um den gesamten Schlüsselteil handelt).

_Reservierte Zeichen_ hingegen sind für spezielle Kontexte reserviert. Sie können nicht normal verwendet werden und sind nur in speziellen Kontexten zulässig, in denen sie eine besondere Bedeutung haben.

Ein Zeichen mit besonderer Bedeutung muss nur in dem Kontext, in dem es seine spezielle Interpretation hat, maskiert werden, wenn diese spezielle Interpretation nicht erwünscht ist. Außerhalb dieses Kontextes kann das Entkommen erlaubt oder verboten sein, abhängig von unserer Haltung zu unnötigem Entkommen (°°).

Ein reserviertes Zeichen muss dagegen maskiert werden, wenn es keine besondere Bedeutung haben soll. Das bedeutet, dass in dem Kontext , in dem es eine besondere Bedeutung hat es entwertet werden kann, die eine besondere Bedeutung zu vermeiden. Außerhalb dieses Kontextes muss es maskiert werden.

Schauen wir uns als Beispiel % . Wenn ein ganzer Schlüsselteil nur % (z. B. /%/ ), wird dieser Teil in einen leeren Teil aufgelöst. In beiden Fällen verhindert der Backslash in /\%/ die spezielle Interpretation und wird nicht in einen Teil umgewandelt, der % . Der Unterschied macht sich jedoch bemerkbar, wenn man sich verschiedene Kontexte wie /a%b/ .

Wenn wir % als _reserviertes Zeichen_ behandeln, dann ist /a%b/ ein unzulässiger Schlüsselname / Teil und wir sollten einen Fehler auslösen. Der richtige Weg, um den nicht entkoppelten Teil a%b mit einem reservierten Charakter zu erreichen, wäre die Verwendung von /a\%b/ .

Wenn wir % als _charakter mit besonderer Bedeutung_ sehen, dann wäre /a%b/ korrekt und würde sich in a%b auflösen. Ob /a\%b/ auch erlaubt ist, hängt von unserer Haltung zu unnötigem Entkommen ab. Wenn es erlaubt ist, entweicht es auch in a%b .

Hinweis: Für / gibt es keine Entscheidung, beide Interpretationen sind gleichwertig, da es keinen Kontext gibt, in dem / keine besondere Bedeutung hat. Für \ wir bereits (in # 3115) beschlossen, es als _reserviertes Zeichen_ zu behandeln, und müssen daher maskiert werden, wenn es selbst nicht als Escape-Zeichen verwendet wird.

Die Entscheidung über natürlich müssen wir auch definieren, in welchen Kontexten diese Zeichen können jetzt oder in Zukunft, haben eine besondere Bedeutung.

Hier gibt es zwei einfache Lösungen:
Behandle alles (außer / und \ ) als _Zeichen mit besonderer Bedeutung_, erlaube unnötiges Entkommen und definiere für die nicht verwendeten, dass die in allen Kontexten eine spezielle Interpretation haben. Die spezielle Interpretation für diese wäre, dass sie einen Schlüsselnamen illegal machen. Daher müssen die nicht verwendeten immer entkommen. Jede andere Zeichenliste kann immer maskiert werden, muss es aber nur sein, wenn wir eine bestimmte spezielle Interpretation verhindern wollen.

--- ---.

(°) Wie in # 3115 angegeben, erleichtert diese Regel das Verständnis des gesamten Systems erheblich. In einem maskierten (gültigen) Schlüsselnamen entgeht ein Backslash immer etwas. In einem nicht entkoppelten (gültigen) Schlüsselnamen ist ein Backslash immer buchstäblich ein Backslash.

(°°) Wenn wir eine sehr strenge Haltung zu unnötigem Entkommen einnehmen, sollte es möglich sein, eine 1: 1-Beziehung zwischen entkommenen und nicht entkoppelten Schlüsselnamen zu erhalten. Dies erfordert natürlich mehr Aufwand bei der Validierung von Schlüsselnamen und hat daher Auswirkungen auf die Leistung (ob diese Auswirkungen in irgendeiner Weise signifikant sind, muss getestet werden).

Wenn Sie \ auflisten, sollten Sie zunächst auch / auf die Liste setzen. Der Schrägstrich ist eindeutig der prototypisch reservierte Charakter (Charakter mit besonderer Bedeutung) in Elektra.

Danke, ich habe es hinzugefügt. Wenn Sie weitere Zeichen finden, können Sie diese einfach zum obersten Beitrag hinzufügen.

Zweitens sind "zum Globbing verwendet" und "zum Verweisen auf parentKey, z. B. im Plugin für bedingte Bedingungen" hier keine gültigen Anwendungsfälle. Dies sind keine besonderen Bedeutungen beim Entweichen.

Ja, natürlich können wir für einige dieser Zeichen auch ein oder zwei andere Escape-Zeichen verwenden. Aber das wird für Benutzer komplizierter?

Was bewirkt der Backslash beim Aufheben des Schlüsselnamens?

Ich hatte vor, dass keyAddBaseName (Schlüssel, "_") tatsächlich \_ hinzufügen wird. Um also ein _ (mit der Bedeutung des Globbing-Zeichens) zu erhalten, müssten Sie keyAddName verwenden.

Beispielsweise verwendet @sanssecours derzeit tatsächlich _ in Schlüsselnamen für das Verzeichniswert-Plugin. Natürlich gibt es keine Möglichkeit, sich dem zu entziehen, da solche entkommenden Engines nicht trivial zu schreiben sind. Ich hatte die Hoffnung, dass wir einen einzigen Ort haben könnten, um eine solche Flucht umzusetzen.

Für die Charaktere, die wir eigentlich "reserviert" machen wollen, müssen wir hier eine Entscheidung treffen. Sind diese Zeichen eine besondere Bedeutung oder tatsächlich reservierte Zeichen?

Wenn sie jetzt keine besondere Bedeutung haben, sind sie reserviert, damit wir ihnen später eine besondere Bedeutung geben können. Wir können zu einem späteren Zeitpunkt nicht "reservieren" oder "eine besondere Bedeutung geben", da Anwendungen möglicherweise bereits solche Zeichen verwenden.

Um es klar zu machen: Im oberen Beitrag sind "besondere Bedeutung" und "reserviert" Synonyme für die entkommende Engine. Und ich würde sie als Synonyme behalten, um die Flucht zu erleichtern.

Reservierte Zeichen hingegen sind für spezielle Kontexte reserviert. Sie können nicht normal verwendet werden und sind nur in speziellen Kontexten zulässig, in denen sie eine besondere Bedeutung haben.

Um diese ganze entkommende Engine gesund zu machen, würde ich einfach annehmen, dass die Sonderzeichen immer etwas Besonderes sind, außer wenn sie entkommen sind.

Insbesondere möchte ich Situationen vermeiden, in denen Zeichen eine besondere Bedeutung erhalten, wenn ein Escape-Zeichen hinzugefügt wurde. Dies ist ein hässlicher Hack und macht zB Regex unnötig kompliziert.

Wenn wir% als Zeichen mit besonderer Bedeutung sehen, wäre / a% b / korrekt und würde sich in a% b lösen.
Auch hier hängt es von unserer Haltung zu unnötigem Entkommen ab, ob / a% b / ebenfalls zulässig ist. Wenn es erlaubt ist, entweicht es auch in a% b.

Genau. Die Engine kann nicht vollständig verhindern, dass Namen mit falschen Bedeutungen erstellt werden. Ich denke, wir sollten nicht versuchen, es zu tun. ZB% in den Platzhaltern müssen eine gerade Anzahl von Vorkommen haben, aber es gibt Ausnahmen. Und vielleicht werden durch eine Erweiterung der Kontextwerte weitere Ausnahmen hinzugefügt.

Wenn wir eine sehr strenge Haltung zu unnötigem Escaping einnehmen, sollte es möglich sein, eine 1: 1-Beziehung zwischen maskierten und nicht entkommenen Schlüsselnamen zu erhalten. Dies erfordert natürlich mehr Aufwand bei der Validierung von Schlüsselnamen und hat daher Auswirkungen auf die Leistung (ob diese Auswirkungen in irgendeiner Weise signifikant sind, muss getestet werden).

Ich denke, unser wichtigstes Ziel sollte sein, dass die Flucht leicht zu verstehen und anzuwenden ist. Bei der vorherigen Flucht wurde versucht, dass jeder Name gültig ist. Solche Ziele verursachen meistens Kopfschmerzen, verbessern jedoch nicht die Benutzerfreundlichkeit. Wenn jemand \ an beliebigen Stellen platziert, ist es in Ordnung, einige Namen abzulehnen. Aber vor Sonderzeichen sollte \ immer gültig sein und jede (zukünftige) Sonderbedeutung wegnehmen.

Ich hatte vor, dass keyAddBaseName (Schlüssel, "_") tatsächlich \_ hinzufügen wird. Um also ein _ (mit der Bedeutung des Globbing-Zeichens) zu erhalten, müssten Sie keyAddName verwenden.

Das ist super verwirrend für mich ...

Die Semantik von keyAddBaseName (Key * key, const char * x) lautet:
x ist ein nicht entflohener Teil. Es wird direkt am Ende von key->ukey hinzugefügt. Die maskierte Form wird am Ende von key->key hinzugefügt.

Die Semantik von keyAddName (Key * key, const char * x) lautet:
x ist ein Escape- Namenssuffix (dh null oder mehr Teile, kein Namespace). Es wird kanonisiert und am Ende von key->key hinzugefügt. Das nicht entflohene Formular wird am Ende von key->ukey hinzugefügt.

Nun möchten Sie, dass keyAddBaseName (key, "_") den Teil \_ zum maskierten Namen und den Teil _ zum nicht entkoppelten Namen hinzufügt. Und das sollte keinen Einfluss auf das Globbing haben. Aber keyAddName (key, "_") sollte eine Bedeutung für das Globbing haben. Was macht es also? _ kann in keiner Weise entkommen, es ist nur ein einzelnes Zeichen. Also müssen wir _ sowohl zum maskierten als auch zum nicht entkommenen Namen hinzufügen. Aber dann produzieren beide Versionen den gleichen Namen, was bedeutet, dass die gleiche Bedeutung für das Globbing haben sollte ...

Derzeit werden tatsächlich _ in Schlüsselnamen für das Verzeichniswert-Plugin verwendet.

AFAIK directoryvalue nur den Schlüsselteil /__directoryvalue/ . Dies kollidiert in keiner Weise mit der Verwendung von /_/ durch Globbing.

Wir können zu einem späteren Zeitpunkt nicht "reservieren" oder "eine besondere Bedeutung geben", da Anwendungen möglicherweise bereits solche Zeichen verwenden.

Es wäre nur eine große Veränderung, wie wir sie jetzt an Schlüsselnamen vornehmen.

Ich denke, wir müssen zwei Dinge unterscheiden:

1. Zeichen, die eine besondere Bedeutung für keySetName (oder genauer elektraKeyNameCanonicalize und elektraKeyNameUnescape ).
2. Zeichen, die für ein Plugin, eine Bibliothek oder einen anderen Teil von Elektra eine besondere Bedeutung haben und sich nicht mit der Manipulation von Schlüsselnamen befassen.

Die erste Gruppe wird eine Form von reserviertem Charakter sein, dessen unsachgemäße Verwendung zu einem fehlgeschlagenen keySetName (und keyNew NULL ). Hier hilft es, mit einem Backslash zu entkommen, da der Backslash keySetName anweist, das folgende Zeichen wörtlich zu nehmen und mögliche Bedeutungen zu ignorieren.

Die zweite Gruppe ist ganz anders. Während keySetName (oder keyAddName , keyAddBaseName usw.) können wir nichts tun, um zu ändern, ob ein Charakter dieser Gruppe für ein Plugin eine besondere Bedeutung hat oder nicht. Es liegt ganz bei dem Plugin zu entscheiden, ob und jede Form des Entkommens des Plugins es ermöglichen könnte, zu verhindern, dass die besondere Bedeutung es zum Plugin schafft. Denken Sie daran, dass wir gesagt haben, dass keySetName fehlschlägt und keyNew für ungültige Namen NULL zurückgibt. In keySetName
Wir können zum Beispiel nicht sagen, dass /# eine besondere Bedeutung hat, /#a nicht erlaubt ist, aber /\# keine besondere Bedeutung hat und /\#a erlaubt ist. Wir haben keine Ahnung, wie dies verwendet werden soll. Wenn wir einige Schlüssel nicht zulassen, kann kein Plugin sie verwenden. (Hinweis: im obigen Absatz: Plugin = Plugin, Bibliothek, Anwendung usw.)

Wenn Sie wirklich vereinheitlichen möchten, wann etwas für ein Plugin / eine Bibliothek eine besondere Bedeutung haben kann, kann ich nur Folgendes sehen:

Definieren Sie einige Fluchtregeln für % , . , / und \ als Auswirkungen auf keySetName . Machen Sie den Array-Index von # 2698. Schlüsselnamen-Teile (maskiert und nicht entkommen), die mit @ müssen die Form (Regex) @[^@]+@.+ . Das Zeichen @ möglicherweise in keinem anderen Kontext angezeigt. Alles andere hat während keySetName keine besondere Bedeutung und kann uneingeschränkt verwendet werden. Plugins, Bibliotheken usw. dürfen keinem einzelnen Zeichen oder einem Schlüsselnamen-Teil eine besondere Bedeutung zuweisen, außer nicht entschlüsselten Schlüsselnamen-Teilen, die mit @ . Ein nicht entkoppelter Schlüsselname des Formulars (Regex) @[^@]+@.+ kann nur eine spezielle Bedeutung für das Plugin haben, das durch den [^@] Teil des Regex benannt wird. Was diese Bedeutung ist, hängt vom Plugin ab und wird durch den Teil nach dem zweiten @ .

Ich erkenne, dass dies völlig anders ist als der derzeitige Ansatz und völlig unangemessen zu implementieren ist, wenn wir 1.0 bald veröffentlichen möchten, aber es ist der einzige funktionierende Ansatz, den ich sehen kann, der es uns ermöglicht, definitiv zu sagen, ob ein Schlüsselteil einen hat besondere Bedeutung oder nicht.

Ich denke, wir müssen zwei Dinge unterscheiden:

Meine Hoffnung war, dass wir diese Unterscheidung verwerfen können, um das Ganze besser verständlich zu machen. Dann fügt keyAddBaseName niemals etwas hinzu, das Elektra eine Bedeutung hat.

Wenn dies nicht möglich ist, besteht die Mindestanforderung darin, dass es möglich ist, eine beliebige Zeichenfolge an keyAddBaseName und dieselbe Zeichenfolge zurückzugewinnen, wenn Sie nach dem Basisnamen mit keyBaseName fragen (siehe # 2698).

Ja, es würde einige Vorkommen von keyAddBaseName brechen,

1. Der Code, der jede Zeichenfolge angenommen hat, kann gesetzt werden oder
2. Der Code, der Arrays angenommen hat, kann hinzugefügt werden.

Mir ist sehr klar, dass wir 1. nicht brechen sollten, dh Code, der davon ausgeht, dass jeder String an keyAddBaseName . "2." ist nicht so wichtig, dies sind einige Vorkommnisse, die behoben werden können.

Ein weiteres Beispiel neben SSID: fstab-Einträge können grundsätzlich alles enthalten, einschließlich /. Oder die Mountpoint-Namen in Elektra.

Dann fügt keyAddBaseName Elektra niemals etwas hinzu, das eine Bedeutung hat.

Ich sehe jetzt, dass dies wieder einmal das Hauptproblem im Herzen von Elektra ist. Alles sollte ein kohärentes und genau definiertes System sein, aber gleichzeitig sollte alles flexibel sein und Plugins sollten so oft wie möglich verwendet werden. Das kann einfach nicht funktionieren.

Das Problem ist speziell der Ausdruck "Bedeutung für Elektra". Wir können sicherstellen, dass keyAddBaseName niemals etwas hinzufügt, das eine Bedeutung für elektra-core , oder klarer ausgedrückt, dass keyAddBaseName sein Argument als neuen, nicht entkoppelten Schlüsselnamen hinzufügt. Für eine Anwendung bedeutet "Elektra" aber auch jedes Plugin von Elektra. In dieser Interpretation wird es sehr schwierig zu verhindern, dass keyAddBaseName etwas "mit Bedeutung" hinzufügt. Jedes Plugin kann jederzeit entscheiden, einem nicht entschlüsselten Schlüsselnamen eine Bedeutung zuzuweisen. Wie gesagt, die einzige Lösung besteht darin, ein sehr restriktives System einzuführen, wie das oben vorgeschlagene mit @ . Wenn Sie sich etwas anderes einfallen lassen, lassen Sie es mich wissen, aber für alles, was ich mir bis dahin ausgedacht habe, habe ich ein Problem gefunden.

Mir ist sehr klar, dass wir 1 nicht brechen sollten, dh Code, der davon ausgeht, dass jede Zeichenfolge an keyAddBaseName übergeben werden kann

Warum? Mir ist alles andere als klar, warum dies vorzuziehen ist. Beispielsweise dürfen UNIX-Dateinamen nicht / und niemand hat jemals gedacht, dass dies ein Problem ist. (Wenn Sie / zulassen, ist das Aufteilen von UNIX-Pfaden in Teile viel einfacher als bei Schlüsselnamen.)

Wir brechen bereits (fast) JEDEN Code, der mit Elektra verbunden ist, indem wir nach dem Namespace die : hinzufügen. Nach dem aktuellen Stand der Dinge funktionieren nur kaskadierende Schlüssel ohne Array-Teile und auch ohne andere Sonderzeichen weiterhin, ohne dass Änderungen erforderlich sind. Abwärtskompatibilität ist lange aus dem Fenster.

"2." ist nicht so wichtig, dies sind einige Vorkommnisse, die behoben werden können.

Da wäre ich mir nicht so sicher. Tatsächlich kenne ich nur einen Teil von Elektra, der wirklich davon ausgeht, dass keyAddBaseName entgeht, und das sind elektra-kdb und die Tools, die Mountpoints erstellen.

fstab-Einträge können grundsätzlich alles enthalten, einschließlich /

Nicht sicher, warum das relevant ist?

Oder die Mountpoint-Namen in Elektra.

Um den Mountpoint user:/my/mount zu erstellen, setzen die Tools die Mountpoint-Konfiguration unter system:/elektra/mountpoints/user:\/my\/mount , aber sie können genauso gut jeden anderen eindeutigen Schlüssel direkt unter system:/elektra/mountpoints , da der eigentliche Mountpoint der ist Wert von zB system:/elektra/mountpoints/user:\/my\/mount/mountpoint . AFAICT system:/elektra/mountpoints könnte genauso gut ein Array sein. Ich habe keinen Ort gefunden, der keyBaseName auf einem Schlüssel direkt unter system:/elektra/mountpoints anruft.

Es könnte einen Ort geben, der mountGetMountpoint oder mountGetBackend , um den Mountpoint abzurufen und system:/elektra/mountpoints/user:\/my\/mount/ zu rekonstruieren, um auf einige der Konfigurationen zuzugreifen, aber das könnte leicht durch Hinzufügen des system:/elektra/mountpoints gelöst werden struct _Backend gespeichert wird.

Zusamenfassend:

Die Mindestanforderung besteht darin, dass es möglich ist, eine beliebige Zeichenfolge an keyAddBaseName und dieselbe Zeichenfolge zurückzugewinnen, wenn Sie nach dem Basisnamen mit keyBaseName fragen

Das ist einfach. Die Kombination mit " keyAddBaseName akzeptiert alle Zeichenfolgen" ist jedoch sehr schwierig oder fast unmöglich.

Ich sehe jetzt, dass dies wieder einmal das Hauptproblem im Herzen von Elektra ist. Alles sollte ein kohärentes und genau definiertes System sein, aber gleichzeitig sollte alles flexibel sein und Plugins sollten so oft wie möglich verwendet werden. Das kann einfach nicht funktionieren.

Ja, aber ich würde es nicht als Problem, sondern als Herausforderung bezeichnen. Wir wollen die bestmögliche Elektra und natürlich treten manchmal widersprüchliche Ziele auf.

Wie gesagt, die einzige Lösung besteht darin, ein sehr restriktives System einzuführen, wie das oben vorgeschlagene mit @.

Ja, ich sehe auch, dass es nicht möglich sein wird, alles zu haben. Mit dem Escape-Array sind wir bereits auf ein Escape-Escape beschränkt, dh wir können andere Zeichen innerhalb der Basisnamen nicht maskieren.

Aber dieses Präfix kann ausreichen. Und dies sollte auf alle oben vorgeschlagenen Zeichen erweiterbar sein. Die Einschränkung wäre, dass entweder der gesamte Schlüsselname-Teil maskiert wird oder gar nichts.

Natürlich wäre das Escape nicht magisch, aber Anwendungen müssten überprüfen, ob die Bedeutung des keyBaseName entfernt wurde, oder wir stellen einen anderen keyUnescapedBaseName bereit, damit API-Benutzer die Zeichenfolge mit oder ohne Escape-Escape haben können.

Warum? Mir ist alles andere als klar, warum dies vorzuziehen ist. Beispielsweise dürfen UNIX-Dateinamen / nicht enthalten, und niemand hat jemals gedacht, dass dies ein Problem ist. (Nicht zulassen / macht das Aufteilen von UNIX-Pfaden in Teile viel einfacher als bei Schlüsselnamen).

Es ist ein Problem für alle, die einen Dateibrowser implementieren. Einige Anwendungen hatten URL-Codierungstechniken, um / in die Dateinamen zu gelangen. Die modernere "Lösung" besteht darin, das Unicode-Zeichen "DIVISION SLASH" (U + 2215) für Schrägstriche zu verwenden.

Beachten Sie außerdem, dass der gesamte Grund für die Existenz von Elektra darin besteht, dass die Semantik des UNIX-Dateisystems nicht für die Konfiguration geeignet ist. In der Konfiguration werden häufig beliebige Sequenzen für Schlüsselteilnamen einschließlich / verwendet und sollten daher unterstützt werden. ZB in YAML / sind Zeichen in Schlüsselnamen erlaubt und auch in TOML gibt es "Quoted Keys".

Wir brechen bereits (fast) JEDEN Code, der mit Elektra verbunden ist, indem wir das: nach dem Namespace hinzufügen. Nach dem aktuellen Stand der Dinge funktionieren nur kaskadierende Schlüssel ohne Array-Teile und auch ohne andere Sonderzeichen weiterhin, ohne dass Änderungen erforderlich sind. Abwärtskompatibilität ist lange aus dem Fenster.

Ja, und ich bin sehr dankbar, dass Sie dies tun. Ich hätte das nicht alleine schaffen können.

Da wäre ich mir nicht so sicher. Tatsächlich kenne ich nur einen Teil von Elektra, der wirklich davon ausgeht, dass keyAddBaseName allem entgeht, und das ist elektra-kdb und die Tools, die Mountpunkte erstellen.

Ein weiterer Teil sind die SSIDs. Dies war kein synthetisches Beispiel, aber Broadcom hat dies für seine Bluetooth-Geräte implementiert. Sie verlassen sich also darauf, dass sie einen beliebigen Basisnamen hinzufügen können.

Das ist einfach. Die Kombination mit "keyAddBaseName akzeptiert alle Zeichenfolgen" ist jedoch sehr schwierig oder fast unmöglich.

Ja, sehr schwer, aber auch eine sehr schöne, einzigartige Funktion, die noch nicht einmal UNIX hatte. Darauf können wir stolz sein.

ZB in YAML / sind Zeichen in Schlüsselnamen erlaubt und auch in TOML gibt es "Quoted Keys".

Ich dachte, wir könnten dies vorstellen, siehe unten.

Ich denke, all dies kann gelöst werden, indem etwas Ähnliches wie "zitierte Schlüssel" eingeführt wird. Ich werde sie _literal Schlüsselteile_ nennen.

Wenn ein Schlüsselteil mit einem @ beginnt (könnte natürlich ein anderes Zeichen sein), ist der folgende Schlüsselteil ein _literaler Schlüsselteil_. Ein Literalschlüsselteil kann JEDE Bytefolge enthalten, die null Bytes enthält.

Ihre ungehinderte Form ist wie folgt:

• Ein _literal key part_ beginnt mit einem @ Zeichen.
• Weitere @ Zeichen werden als @@ codiert.
• Null Bytes werden als @0 codiert.
• @ darf sonst nicht vorkommen.
• Wie immer beendet ein Null-Byte den Schlüsselteil.

Das maskierte Formular ist etwas anders, um das Drucken zu vereinfachen:

• Ein _literal key part_ beginnt mit einem @ Zeichen.
• Der _literal key part_ wird NICHT durch ein / . Nur ein weiteres @ gefolgt von einem / oder einem Null-Byte (Ende der Zeichenfolge), beendet den _literal-Schlüsselteil.
• Jedes Byte kann als @XX@ codiert werden, wobei XX die hexadezimale Form des Bytes ist. Daher müssen @ Zeichen als @40@ codiert werden.

Jetzt akzeptieren keySetBaseName und keyAddBaseName JEDEN gültigen, nicht entkoppelten Schlüsselteil als Argumente. Sie setzen / fügen ihr Argument unverändert als letzten Teil des nicht entkoppelten Schlüsselnamens hinzu. Daher gibt keyBaseName das gleiche Argument zurück. Zusätzlich verwandeln keySetBaseName und keyAddBaseName den nicht entkoppelten Teil in seine maskierte Form und setzen / fügen ihn als letzten Teil des maskierten Namens hinzu.

Um das Problem zu lösen, dass "wir alles als Schlüsselelement hinzufügen möchten", führen wir Folgendes ein:

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

Diese Funktionen akzeptieren JEDE Byte-Sequenz als bytes Argument. Sie verwandeln das Argument dann in einen nicht gekappten _literalen Schlüsselteil_, indem sie ihm ein @ voranstellen, andere @ durch @@ und null Bytes durch @0 ersetzen. Dies wird dann an keySetBaseName oder keyAddBaseName .

Um die Dekodierung von _literal key part_ zu vereinfachen, können wir der öffentlichen API auch Dekodierungsfunktionen hinzufügen.

Ich mag das viel besser, weil es sehr deutlich macht, wann der Benutzer beabsichtigt, dem Schlüsselnamen beliebige Dinge hinzuzufügen, und wann dies nicht der Fall ist.

keySet / AddLiteralBaseName ist ein Vorschlag zum Hinzufügen einer neuen Funktion. Derzeit haben wir keine Möglichkeit, Null-Bytes in Schlüsselnamen zu codieren. Wenn jemand dies benötigt, können wir auf Ihren Vorschlag zurückkommen.

Für den Moment benötigen wir jedoch eine gute Semantik für keyAdd / SetBaseName. Wie sehr lange beschrieben, sollte dies idealerweise eine beliebige Zeichenfolge sein, da ansonsten viele Plugins und Anwendungen fehlerhaft sind, da sie nicht erwarten, dass einige Zeichenfolgen nicht funktionieren. #_10 ist ein gültiger Teil des Schlüsselnamens. Er kann als Teil des Schlüsselnamens in praktisch allen Speicher-Plugins oder -Anwendungen verwendet werden. Wir können dies nicht diskutieren. Es ist definitiv keine gute Idee, ein Speicher-Plugin ausfallen zu lassen, da es beim Parsen irgendwo #_10 als Schlüsselnamen gefunden hat. Und es ist auch keine gute Idee, von ihnen zu verlangen, dass sie eine andere API mit einem Größenargument verwenden, wenn sie ohnehin keine Null-Bytes haben. Tatsächlich ist der Grund für die Existenz von keyAdd / SetBaseName, dass Fälle wie #_10 oder / keine spezielle Behandlung erfordern.

Übrigens. Vielleicht ist es am besten, wenn wir uns treffen, zB am Dienstag?

Derzeit haben wir keine Möglichkeit, Null-Bytes in Schlüsselnamen zu codieren. Wenn jemand dies benötigt, können wir auf Ihren Vorschlag zurückkommen.

Dies ist der am wenigsten wichtige Punkt des Vorschlags. Es erlaubt nur null Bytes, weil ich keinen Grund sehe, warum es nicht würde.

Jedenfalls gibt es bereits einen Anwendungsfall:

Ein weiterer Teil sind die SSIDs. Dies war kein synthetisches Beispiel, aber Broadcom hat dies für seine Bluetooth-Geräte implementiert. Sie verlassen sich also darauf, dass sie einen beliebigen Basisnamen hinzufügen können.

Abgesehen von der Tatsache, dass SSIDs nichts mit Bluetooth zu tun haben, definiert EEE 802.11 eine SSID eindeutig als eine Byte-Sequenz mit einer Länge von bis zu 32 Bytes. Entweder führt Broadcom bereits eine Vorverarbeitung durch, um null Bytes zu verarbeiten, oder der Code ist bereits fehlerhaft. In jedem Fall ist dies eindeutig ein Anwendungsfall für die Codierung von Null Bytes in Schlüsselbasisnamen.

Auf jeden Fall habe ich keine Ahnung von möglichen zukünftigen Erweiterungen des Satzes von Sonderzeichen, aber für den aktuellen Satz denke ich, dass die in # 3115 implementierte Lösung so funktionieren könnte, wie sie ist.

Wenn wir das Szenario von https://github.com/ElektraInitiative/libelektra/issues/2698#issuecomment -554680422 in dieser Version ausprobieren, geschieht Folgendes:

Das Aufrufen von keyAddBaseName (key, "#_10") führt dazu, dass sowohl der letzte Teil von key->key als auch von key->ukey #_10 . Warum? Weil #_10 ein gültiges Array-Element ist. Ja, wenn #_10 eine SSID wäre, würden wir sie nicht als Array-Element betrachten, aber das Globbing mit # würde dazu passen, aber ist das wirklich wichtig?

Wenn wir ein ungültiges Array-Element wie #10 oder #abc , wird keyAddBaseName ausgeblendet und der letzte Teil des nicht entkoppelten Namens lautet #10 oder #abc , während der letzte Teil des maskierten Namens \#10 oder \#abc .

Ich habe noch nicht über die theoretischen Regeln nachgedacht, die wir benötigen, damit dies für zukünftige Erweiterungen funktioniert, aber ich denke, wir können es vorerst so belassen. Es wäre schön, Array-Elemente ohne das Startzeichen zu haben, aber ist das wirklich wichtig? Speicher-Plugins können Arrays unterschiedlich codieren, wenn sie ein Problem mit dem Zeichen # haben. Für die Befehlszeile sollten wir nur kdb array* Befehle hinzufügen, die normale ganzzahlige Parameter annehmen, z. B. kdb arrayset /my/array 10 a .

Übrigens. Vielleicht ist es am besten, wenn wir uns treffen, zB am Dienstag?

Dienstag ist schlecht für mich ... Ich werde Ihnen eine E-Mail senden.

Abgesehen von der Tatsache, dass SSIDs nichts mit Bluetooth zu tun haben,

Ich meinte Blueray-Geräte (die WiFi-Fähigkeit haben).

EEE 802.11 definiert eine SSID eindeutig als eine Byte-Sequenz mit einer Länge von bis zu 32 Bytes. Entweder führt Broadcom bereits eine Vorverarbeitung durch, um null Bytes zu verarbeiten, oder der Code ist bereits fehlerhaft. In jedem Fall ist dies eindeutig ein Anwendungsfall für die Codierung von Null Bytes in Schlüsselbasisnamen.

Ja, du hast recht. Aber es ist eine neue Funktion. Eine Zeichenfolge in keySetBaseName ist keine neue Funktion.

Weil # _10 ein gültiges Array-Element ist. Ja, wenn # _10 eine SSID wäre, würden wir sie nicht als Array-Element sehen, aber das Globbing mit # würde dazu passen, aber ist das wirklich wichtig?

Nein, das spielt keine Rolle.

Es wäre schön, Array-Elemente ohne das Startzeichen zu haben, aber ist das wirklich wichtig?

Nein, das Wichtigste ist, dass jeder String an keySetBaseName übergeben werden kann und keyBaseName den zuvor eingegebenen Wert zurückgibt. Mit der Notwendigkeit von Startcharakteren in Arrays kann ich definitiv (und glücklich) leben.

[...] und für die Befehlszeile sollten wir nur kdb array * -Befehle hinzufügen, die normale ganzzahlige Parameter annehmen, z. B. kdb arrayset / my / array 10 a.

Hört sich nach einem guten Plan an.

Nachdem ich alles noch einmal überprüft habe, denke ich, dass es nur einen Konflikt gibt. Die folgenden Aussagen können nicht vereinheitlicht werden.

1. Ein nicht entkappter Schlüsselteil kann ein beliebiges Byte enthalten, das nicht Null ist.
2. Ein Teilstring eines nicht entkappten Schlüsselteils kann eine Eigenschaft des nicht entkappten Schlüsselteils bestimmen.

In unserem speziellen Fall. Die erste Aussage ergibt sich aus den Garantien für keyBaseName et al. zusammen mit der Tatsache, dass Sie nicht möchten, dass keyAddBaseName ein Argument zurückweist. Darüber hinaus ist der Vorschlag "Nicht entformte Schlüsselteile, die mit # sind immer Array-Indizes" ein Sonderfall von 2.

Dies bedeutet im Wesentlichen, dass wir, um 1 zu behalten, was wir wollen, immer wieder ein vollständiges, nicht entkoppeltes Schlüsselteil überprüfen müssen, wenn Sie eine bestimmte Eigenschaft testen möchten. Insbesondere müssen Sie den vollständigen nicht entkoppelten Schlüsselteil überprüfen, um zu wissen, dass es sich um einen Array-Index handelt. Ich finde das eine unglückliche Situation, aber es scheint unvermeidlich.

Dies bedeutet auch, dass wir immer noch die ganze Sache "Escape-Schlüsselteile, die ausschließlich aus Ziffern bestehen, sind Array-Indizes" ausführen können. Der Nebeneffekt wäre, dass im SSID-Beispiel keyAddBaseName (key, "#_10") zu einem Escape-Namen führen würde, der mit /10 anstelle von /#_10 endet. Aber da Sie bereits die Tatsache akzeptiert haben, dass keyAddBaseName (key, "#abc") einen maskierten Namen ergibt, der auf /\#abc endet, gehe ich davon aus, dass dies auch kein Problem wäre?
Dies zu implementieren wäre eine größere Aufgabe, daher wäre es eine Folge-PR zu # 3115. Ich müsste überprüfen, ob alles, was mit Array-Indizes funktioniert, tatsächlich den nicht entkoppelten Namen verwendet, und zusätzlich alles aktualisieren, was Schlüssel mit Array-Teilen erstellt.

Eigentlich wird 2. nicht unbedingt benötigt. Wir können auch eine dritte Zeichenfolge speichern, die den zurückzugebenden Basisnamen enthält (möglicherweise nur dann, wenn tatsächlich benötigt wird, um nicht zu viel Speicher zu verschwenden).

Dies umzusetzen wäre eine größere Aufgabe

Das ist nicht gut, wir müssen auch irgendwie damit ein Ende haben. Vielleicht rettet uns die 3. Saite, wir können dies später optimieren (falls erforderlich).

Entweder machen wir eine vollständige Liste der priorisierten Anforderungen in einer Entscheidung oder wir erfüllen? Die Entscheidung wird sowieso praktisch sein, damit die Leute später verstehen, warum wir das so gemacht haben und welche Anforderungen wir für andere Anforderungen geopfert haben.

Eigentlich wird 2. nicht unbedingt benötigt.

Wie ich schon sagte, es war ein Vorschlag. Es wäre schön zu haben, aber leider funktioniert es nicht.

Wir können auch eine dritte Zeichenfolge speichern, die den zurückzugebenden Basisnamen enthält (möglicherweise nur dann, wenn tatsächlich benötigt wird, um nicht zu viel Speicher zu verschwenden).

Wir müssten eine ganze 3. Version des Schlüsselnamens speichern, sonst würde keySetBaseName (key, NULL) richtig funktionieren.

Im Moment gibt es nicht viele Eigenschaften, die ein Schlüsselteil haben kann. Zumindest keine Immobilien, die in ganz Elektra interessant sind. "Ist es ein Array-Index-Teil?" ist in der Tat der einzige, an den ich denken kann. Wenn wir in Zukunft mehr Eigenschaften haben (z. B. wenn wir das Konzept der "kontextuellen Platzhalter" zum Kern hinzufügen), können wir über Optimierungen nachdenken.

Das ist nicht gut, wir müssen auch irgendwie damit ein Ende haben.

Ich weiß, genau deshalb habe ich gesagt, dass ich es in # 3115 nicht tun werde. Wenn wir uns dafür entscheiden, werde ich eine weitere PR eröffnen. Diese zweite PR wird eine Menge Arbeit sein und eine bahnbrechende Veränderung sein. Es sollte sich jedoch um eine viel kleinere Änderung handeln, und (die meisten) anderen gleichzeitigen PRs sollten nicht so stark betroffen sein wie beim Zusammenführen von # 3115.

Entweder machen wir eine vollständige Liste der priorisierten Anforderungen in einer Entscheidung oder wir erfüllen?

Ich werde eine Dokumentation schreiben, einschließlich einer Entscheidung, wenn der Code von # 3115 fertig ist. Die derzeit offene Frage lautet:

1. Welche Zeichen können außer / und \ am Anfang eines Schlüsselteils eine besondere Bedeutung haben?
   In # 3115 sind dies derzeit # , % , . und @ .
2. Was ist die besondere Bedeutung? Dies kann je nach Rest des Schlüsselteils unterschiedlich sein.
   In # 3115 haben wir Folgendes:
   
   
   
   • # bedeutet Array-Teil, wenn der Rest des Schlüsselteils nur aus Ziffern besteht oder zuerst n Unterstriche und dann n + 1 Ziffern ( n >= 0 ) und sonst nichts. Ein Teil von nur # hat im Allgemeinen keine besondere Bedeutung (dies kann bedeuten, dass einige Teile von Elektra mit einem Array versehen sind). Jeder andere Teil, der mit # beginnt, bedeutet, dass der Schlüsselname ungültig ist.
   
   
   • % bedeutet leeres Teil, wenn das Teil nur % . Jeder andere Teil, der mit % beginnt, bedeutet, dass der Schlüsselname ungültig ist.
   
   
   • . hat nur dann eine besondere Bedeutung, wenn das Teil nur . oder genau .. . Alle anderen Teile, die mit . derzeit keine besondere Bedeutung, dh der Schlüsselname ist nicht ungültig. (Zuvor hat ein Teil, der mit . beginnt, einen Schlüssel inaktiv gemacht.)
   
   
   • @ ist reserviert. Jeder Teil, der mit @ beginnt, bedeutet, dass der Schlüsselname ungültig ist.
   
   
3. Sollte das Entkommen der Sonderzeichen von 1 immer erlaubt sein oder nur bei Bedarf?
   In # 3115 ist das Entkommen immer erlaubt.
4. Wollen wir, dass Schlüsselteile, die ausschließlich aus Ziffern bestehen, als Array-Teile interpretiert werden? Wenn ja, wie lautet die kanonische Darstellung? Nur Ziffern, beginnend mit # dann nur Ziffern oder das Gleiche wie die nicht entflohene Version, dh # und Unterstriche?
   In # 3115 benötigen wir immer Array-Teile, um mit # und ihre kanonische Darstellung ist dieselbe wie die ohne Flucht.

Meine vorgeschlagenen Antworten sind:

1. # , % , . , @ , $ , & und ? sollten sein genug für mögliche zukünftige Verwendungen. Insbesondere denke ich, wir sollten nicht _ reservieren, die nur Probleme verursachen.
2. Wie wir es in # 3115 haben. $ , & und ? sind für die zukünftige Verwendung wie @ reserviert.
3. Immer erlaubt.
4. Persönlich bin ich dagegen. Das Startzeichen erleichtert das Erkennen von Array-Teilen beim Betrachten von Schlüsselnamen. Wie in # 2698 vorgeschlagen, sollten Kollisionen mit Sonderzeichen in Speicherformaten durch Speicher-Plugins gelöst werden, nicht durch den Kern, und das Tool kdb sollte nur über spezielle Array-Befehle verfügen.

Etwas unabhängig: Es könnte möglich sein, directoryvalue in eine Bibliothek umzuwandeln (oder sie sogar zum Teil des Kerns zu machen) und ihr eine private Schnittstelle zu geben, über die Schlüssel erstellt werden können, die über die öffentliche API nicht möglich wären. Dann müssten wir uns wegen des Namens __directoryvalue keine Sorgen um Kollisionen machen. Eines der reservierten Zeichen würde dafür verwendet. Ich habe nicht viel darüber nachgedacht, aber es könnte eine gute Idee sein, da die meisten Speicherformate für die menschliche Lesbarkeit gut sind und keine Schlüssel mit einem Wert und Schlüsseln darunter unterstützen.

Welche Zeichen außer / und \ können am Anfang eines Schlüsselteils eine besondere Bedeutung haben?
In # 3115 sind dies derzeit #,% ,. und @.

In diesem Thema geht es im Wesentlichen darum, Zeichen zu sammeln, die möglicherweise eine besondere Bedeutung haben (jetzt oder reserviert).

Sollte das Entkommen der Sonderzeichen von 1 immer erlaubt sein oder nur bei Bedarf?

Ja, immer erlaubt sein.

Wollen wir, dass Schlüsselteile, die ausschließlich aus Ziffern bestehen, als Array-Teile interpretiert werden? Wenn ja, wie lautet die kanonische Darstellung? Nur Ziffern, beginnend mit einem #, dann nur Ziffern oder dasselbe wie die nicht entflohene Version, dh # und Unterstriche?

Dies hängt stark davon ab, welche Eigenschaften von Basisnamen wir verlieren. Aus Benutzersicht ist es "nett", wenn kein # benötigt wird. Aus API-Sicht ist es sehr wichtig, dass keySet/AddBaseName einfach funktioniert.

Insbesondere denke ich, wir sollten nicht reservieren, dass dies nur Probleme verursachen wird.

Und um das Globbing auf * zu ändern?

Das Startzeichen erleichtert das Erkennen von Array-Teilen beim Betrachten von Schlüsselnamen.

Ich denke nicht, dass es ein großes Problem ist: Zahlen innerhalb einer Zeichenfolge sind auch ziemlich leicht zu erkennen:

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

Dann müssten wir uns wegen des Namens __directoryvalue keine Sorgen um Kollisionen machen.

Bei korrekter Implementierung müssen wir uns keine Sorgen machen, auch wenn es als Plugin implementiert ist. Das Plugin könnte dem bereits vorhandenen __directoryvalue entkommen.

Mein Traum ist es, dass keySetBaseName dem Verzeichniswert entgeht (ein Unterstrich oder @ würde ausreichen), aber das Verzeichniswert-Plugin würde keyAddName verwenden, um einen unformatierten Verzeichniswert innerhalb des Schlüsselnamens zu erhalten. (Dies wäre geschützt, da Unterstrich oder @ ein reserviertes Zeichen ist, das nicht für Anwendungen verwendet werden darf.)

Hoffentlich können wir dies heute diskutieren. Ich hoffe, dass wir auf diese Weise leichter zu dem Schluss kommen können.

Dies hängt stark davon ab, welche Eigenschaften von Basisnamen wir verlieren.

Wie gesagt, wir sollten im Vergleich zum aktuellen Status von # 3115 nichts verlieren, aber wir würden auch nicht unbedingt viel gewinnen. Die Hauptfrage ist, wie viel mehr Arbeit wir in die Änderung des Schlüsselnamens investieren möchten. Reden wir heute darüber.

Und um das Globbing auf * zu ändern?

* bereits eine Bedeutung für die Globbing-Bibliothek. Es bedeutet jedes Schlüsselteil. # entspricht nur Array-Teilen und _ entspricht Nicht-Array-Teilen.

Ich denke nicht, dass es ein großes Problem ist: Zahlen innerhalb einer Zeichenfolge sind auch ziemlich leicht zu erkennen

Das bin vielleicht nur ich, aber ich habe die /1/ zuerst nicht entdeckt.

Bei korrekter Implementierung müssen wir uns keine Sorgen machen, auch wenn es als Plugin implementiert ist. Das Plugin könnte dem bereits vorhandenen __directoryvalue entkommen.

In # 3256 finden Sie eine alternative Lösung mit Metakeys.

Mein Traum ist es, dass keySetBaseName dem _directoryvalue entgeht

Ich bin stark dagegen. Der Kern sollte sich in keiner Weise damit befassen, was Plugins tun oder welche Anforderungen sie haben. Es stellt auch einen schlechten Präzedenzfall dar. Was ist, wenn ein anderes Plugin _averyspecialkey für etwas verwendet? Werden wir keySetBaseName jedes Mal aktualisieren, wenn dies passiert?

Ergebnis des Gesprächs:

• Die Eigenschaften der Basisnamen scheinen bereits mehr oder weniger so zu sein wie zuvor
• Arrays beginnen weiterhin mit # (_ wird jedoch nicht benötigt)
• Zeichen oben werden maskiert, wenn sie sich an der ersten Position befinden, außer: #
• keySetBaseName wird und kann nicht für neue Zeichen aktualisiert werden. Die obige Liste (nach Fertigstellung) ist eine vollständige Liste für Elektra 1.0

Zeichen oben werden maskiert, wenn sie sich an der ersten Position befinden, außer: #

Das aktuelle Verhalten (in # 3115) von keySetBaseName und keyAddBaseName wird durch diese Funktion definiert:

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

Wir entkommen nur, wenn dies erforderlich ist, um ein unnötiges Entkommen im entkommenen Namen zu vermeiden.

Auch seit Sie gefragt haben, ob es eine 1: 1-Beziehung zwischen dem Namen des Escape- und des Escape-Schlüssels gibt:

Nein, da ist kein. Wir haben beschlossen, unnötiges Entkommen zuzulassen:

Sollte das Entkommen der Sonderzeichen von 1 immer erlaubt sein oder nur bei Bedarf?

Ja, immer erlaubt sein.

Dies bedeutet, dass z. B. /key/%abc und /key/\%abc unterschiedliche Escape-Schlüsselnamen für denselben nicht entschlüsselten Schlüsselnamen sind. Nämlich der mit dem kaskadierenden Namespace und den beiden Teilen key und %abc .

Wenn wir eine 1: 1-Beziehung sicherstellen möchten, können wir entweder sagen, dass Escape nur bei Bedarf zulässig ist (gefällt Ihnen nicht), oder unnötige Backslashes während des Kanonisierungsschritts entfernen.
In jedem Fall erfordert die 1: 1-Beziehung, dass sich keySetBaseName und keyAddBaseName wie oben beschrieben verhalten, dh es muss wissen, wann eine Flucht erforderlich ist.

Persönlich denke ich nicht, dass die 1: 1-Beziehung erforderlich ist. Wir brauchen nur eine: 1-Beziehung, damit ksLookup funktioniert. Normalerweise sollte es kein Problem sein, wenn wir /key/\%abc nachschlagen und /key/%abc zurückerhalten oder umgekehrt.

Vielen Dank, dass Sie das Hin- und Rückflugverhalten untersucht haben. Ja, die Suche ist keine große Sache (aufgrund der Kaskadierung ist sie bereits 1: n), aber dass Schlüssel mit unterschiedlichen Namen sich selbst entfernen, wenn sie an das Keyset angehängt werden, ist hässlich. Und natürlich ist es kein Roundtrip, ein weiteres wichtiges Ziel: Jedes KeySet sollte nach der Serialisierung und Serialisierung genau gleich sein, und dies wäre nicht gegeben, wenn \% und % "identisch sind "in der internen Darstellung.

Haben Sie vielleicht eine Lösung für das Problem mit ksAppend und Roundtripping?

Es ist eine Frage der Definition. Was identifiziert einen Schlüssel eindeutig?

Die technische Antwort ist der ungehinderte Name. Es ist das, was ein KeySet verwendet, um zwischen Schlüsseln zu unterscheiden.
Benutzer müssen sich nur daran gewöhnen, zu wissen, wann zwei Schlüsselnamen identisch sind. Es ist ähnlich wie beim Erkennen, dass die Brüche 2/3 und 4/6 sind.

Wenn Sie weiterhin die 1: 1-Beziehung wünschen, muss das Entkommen nur bei Bedarf zulässig sein. Die Implementierung ist kein größerer Aufwand, kann aber für die Benutzer ärgerlich sein.

Es ist eine Frage der Definition. Was identifiziert einen Schlüssel eindeutig?

Bisher genügte es zu sagen, "der Name kennzeichnet einen Schlüssel", da zwischen entkommen und nicht entkommen 1: 1 lag. Sie wurden nur als Leistungsverbesserung gespeichert. (Raum gegen Zeit)

Ich würde es vorziehen, wenn es so bleiben kann.

Wenn Sie weiterhin die 1: 1-Beziehung wünschen, muss das Entkommen nur bei Bedarf zulässig sein. Die Implementierung ist kein größerer Aufwand, kann aber für die Benutzer ärgerlich sein.

Warum sollte es nerven?

Meine Idee von \#123 vs. #123 war, dass es nicht der gleiche Schlüsselname ist und nicht die gleiche Bedeutung hat (einer bedeutet das wörtliche #123 , der andere ist der 124 .. Array-Eintrag). Sie hätten beide unterschiedliche entkommene und nicht entflohene Namen.

Wenn sie jetzt denselben Namen haben, können wir einfach keyAddName(k, "\\#123") ablehnen. Es hat keinen Vorteil, es zu haben, oder gibt es?

Meine Idee von \#123 vs. #123 war, dass es nicht der gleiche Schlüsselname ist und nicht die gleiche Bedeutung hat (einer bedeutet das wörtliche #123 , der andere ist der 124 .. Array-Eintrag). Sie hätten beide unterschiedliche entkommene und nicht entflohene Namen.

Dieses Beispiel zeigt nichts. Offensichtlich haben \#123 und #123 unterschiedliche Versionen ohne Flucht, sonst wäre es nicht möglich, den Teil ohne Flucht #123 in irgendeiner Weise zu bekommen.

Arrays sind auch ein schlechtes Beispiel, da wir gesagt haben, dass # einen gültigen Array-Teil einführen oder maskiert werden muss, um einfache Fehler zu vermeiden. Schauen wir uns stattdessen % .

Wenn der maskierte Teil /%/ , erhalten wir ein leeres nicht entkapptes Teil und wenn es /\%/ wir den nicht entkappten Teil % . Offensichtlich müssen beide gültige Escape-Schlüsselteile sein. So weit, ist es gut.
Die Frage betrifft jetzt die Teile /%abc/ und /\%abc/ . Beide sind dem nicht entflohenen Teil %abc . Sind beide erlaubt oder ist einer von ihnen ungültig? Wenn beide erlaubt sind, haben wir keine 1: 1-Beziehung.

Das habe ich gemeint mit:

Sollte das Entkommen der Sonderzeichen von 1 immer erlaubt sein oder nur bei Bedarf?

Worauf Sie geantwortet haben:

Ja, immer erlaubt sein.

Was ich als /%abc/ und /\%abc/ interpretiert habe, ist erlaubt. Mir ist jetzt klar, dass Sie vielleicht "Ja, immer erforderlich" gemeint haben, dh nur /\%abc/ ist gültig.

Sowieso...
Wir haben hier zwei Möglichkeiten:

1. Ein reserviertes Zeichen muss ein gültiges Teil mit besonderer Bedeutung einführen oder es muss maskiert werden.
   Im obigen Beispiel bedeutet dies, dass nur /\%abc/ gültig ist.
2. Ein reserviertes Zeichen darf nur maskiert werden, wenn das Teil ohne Escapezeichen eine besondere Bedeutung hätte.
   Im obigen Beispiel bedeutet dies, dass nur /%abc/ gültig ist.

Die Auswahl kann unabhängig für jedes der reservierten Zeichen getroffen werden. Pro Zeichen kann nur eine dieser Optionen ausgewählt werden, um die 1: 1-Beziehung beizubehalten.

In # 3115 ist es derzeit Option 1 für # und Option 2 für . und % . Für @ beide Optionen gleich, es ist immer ein Escapezeichen erforderlich. Es gibt keine gültigen Teile, die mit @ . Ich muss überprüfen, ob alles andere korrekt ist, aber ich denke, wir haben gerade eine 1: 1-Beziehung in # 3115.

Vielen Dank für die ausführliche Erklärung. Ja, es ist nicht so wichtig, dass /%abc/ mit einem einzigen Schrägstrich entkommen kann. Roundtripping ist viel wichtiger. Wir können auch etwas anderes verwenden, um dem zu entkommen (in der obigen Ebene).

Es gibt keine gültigen Teile, die mit @ beginnen.

Wie wird es funktionieren, wenn wir @ eine Bedeutung zuweisen?

Ich muss überprüfen, ob alles andere korrekt ist, aber ich denke, wir haben gerade eine 1: 1-Beziehung in # 3115.

Vielen Dank: 100:

Wie wird es funktionieren, wenn wir @ eine Bedeutung zuweisen?

Sie haben Recht, um zukünftige Kompatibilität sicherzustellen, müssen wir Option 1 wählen. Es ist leicht zu sehen:
/\%abc/ , /%/ und /\%/ sind nicht gültig, /%abc/ jedoch nicht. Alle Teile, die mit @ sind derzeit ungültig, aber das Beginnen mit \@ ist zulässig und wird weiterhin korrekt sein, wenn einige Teile, die mit @ , gültig werden.

Ich habe den Regelsatz gelöscht, den ich zuvor gepostet habe, weil ich nach dem Spielen mit einer ANTLR-Grammatik festgestellt habe, dass die Regeln nicht helfen. Ich denke, eine 1: 1-Beziehung zu haben UND die Abwärtskompatibilität sicherzustellen, wenn reservierten Zeichen eine Bedeutung gegeben wird, ist grundsätzlich unmöglich.

Nehmen wir als Beispiel @ . Derzeit sind nur Teile gültig, die mit \@ beginnen. Teile, die mit @ sind immer ungültig. Teile des Formulars \@XYZ ( XYZ ist willkürlich) werden in @XYZ .

Jetzt beschließen wir, die Bedeutung für @ einzuführen. Alle Teile des Formulars @XYZ ( XYZ willkürlich), für die das Prädikat foo(XYZ) ( foo ist ein String-Prädikat) wahr sind, werden jetzt in bar(XYZ) ( bar ist eine Funktion, die Zeichenfolgen Zeichenfolgen zuordnet). Um die 1: 1-Beziehung aufrechtzuerhalten, müssen wir natürlich sicherstellen, dass kein anderer Teil in bar(XYZ) entweicht. Dies bedeutet jedoch, dass einige derzeit gültige Schlüssel ungültig werden, da derzeit Schlüssel mit beliebigen Namen ohne Escapezeichen abgerufen werden können. Dies unterbricht die Kompatibilität. (Hinweis: Es ist möglicherweise möglich, die 1: 1-Beziehung und das lose Roundtrip-Verhalten zwischen den Versionen "keine Bedeutung für @ " und "Bedeutung für @ " beizubehalten, aber das ist nur eine anderer Bruchwechsel.)

Ich habe vielleicht eine Lösung dafür, aber ich weiß bereits, dass es Ihnen nicht gefallen wird, da es darum geht, bestimmte ungehinderte Namen nicht zuzulassen.

Die Erklärung meiner Lösung wurde ziemlich lang, deshalb habe ich sie in # 3115 abgelegt.

Die Grundidee ist:

• Nicht mehr alle Bytesequenzen sind nicht mehr verwendete Schlüsselnamen. Einige C-Strings sind keine gültigen nicht genannten Schlüsselnamen mehr.
• Dies ermöglicht eine zukunftssichere 1: 1-Beziehung zwischen maskierten und nicht entkommenen Schlüsselnamen. Zeichenfolgen können gültige Schlüsselelemente werden, aber sobald eine Zeichenfolge gültig ist, kann sie nicht mehr ungültig werden.

Die ausführliche Erklärung und deren Bedeutung finden Sie hier . Sie können hier Kommentare hinzufügen: https://github.com/ElektraInitiative/libelektra/commit/86d8e7806bfb92e95a7c519e09e95fa278eadb05

Vielen Dank, dass Sie daran gearbeitet haben! @sanssecours kannst du es dir vielleicht ansehen, wenn dir die Idee auch gefällt?

Ich habe vielleicht eine Lösung dafür, aber ich weiß bereits, dass es Ihnen nicht gefallen wird, da es darum geht, bestimmte ungehinderte Namen nicht zuzulassen.

Übrigens. Es ist nicht so, dass "Ich werde es nicht mögen", es ist so, dass niemand Elektra mögen wird, wenn alle Speicher-Plugins fehlerhaft sind, weil sie einige Zeichenfolgen nicht akzeptieren können.

sind fehlerhaft, weil sie einige Zeichenfolgen nicht akzeptieren können

Es ist nicht fehlerhaft, wenn wir es so definieren. JSON erfordert ein Escapezeichen ähnlich wie C-Strings. Niemand beschwert sich darüber. Für jedes Elektra-Plugin, das JSON verwendet, müssen nur noch ein paar Escapezeichen verwendet werden.

Während es aus den detaillierteren Definitionen ersichtlich sein sollte, hätte ich vielleicht explizit angeben sollen, dass keine tatsächliche Funktionalität verloren geht. In einigen Fällen ist es nur etwas komplizierter.

Für jede Folge von Bytes gibt es immer noch einen einzelnen Namen ohne Schlüssel, der diese Folge von Bytes darstellt. Es ist nur so, dass die ursprüngliche Folge von Bytes und der nicht entkoppelte Schlüsselname, der sie darstellt, nicht mehr immer dieselbe sind.

Es ist nicht fehlerhaft, wenn wir es so definieren. JSON erfordert ein Escapezeichen ähnlich wie C-Strings. Niemand beschwert sich darüber. Für jedes Elektra-Plugin, das JSON verwendet, müssen nur noch ein paar Escapezeichen verwendet werden.

Sie vergleichen hier Äpfel mit Bananen. JSON ist ein Serialisierungsformat. Wir diskutieren hier eine Datenstruktur (KeySet). Auf Serialisierungsebene müssen Speicher-Plugins weiterhin Schlüsselnamen und Schlüsselwerte maskieren / entfernen, damit Trennzeichen unterschieden werden können.

Während es aus den detaillierteren Definitionen ersichtlich sein sollte, hätte ich vielleicht explizit angeben sollen, dass keine tatsächliche Funktionalität verloren geht. In einigen Fällen ist es nur etwas komplizierter.

Ohne API ist es schwierig zu sagen, was "etwas komplizierter" bedeutet.

Es ist nur so, dass die ursprüngliche Folge von Bytes und der nicht entkoppelte Schlüsselname, der sie darstellt, nicht mehr immer dieselbe sind.

Ich denke, wir könnten damit leben.

Ich mache mir nur Sorgen, dass diese Änderung zu groß sein wird (es scheint, dass auch eine Änderung in allen Speicher-Plugins erforderlich sein wird) und wir werden sie nicht beenden können. Vielleicht ist es besser, die natürliche Sortierung zu vergessen, die den größten Teil dieser Probleme verursacht hat?

Vielleicht ist es besser, die natürliche Sortierung zu vergessen, die den größten Teil dieser Probleme verursacht hat?

Die natürliche Sortierung hat damit nichts zu tun. AFAIK, es wird nirgendwo im Vorschlag erwähnt. Das Problem besteht darin, Zeichen für die zukünftige Verwendung umzukehren und gleichzeitig zu vermeiden, dass Änderungen unterbrochen werden.

Ohne API ist es schwierig zu sagen, was "etwas komplizierter" bedeutet.

Die API ist im Vorschlag enthalten. In diesem Fall bedeutet "etwas komplizierter" nur, zwischen zwei Operationen zu wählen ( pushL und pushU , Namen sind Platzhalter), anstatt immer dieselbe zu verwenden ( keyAddBaseName ). Und manchmal wird ein führender Backslash ignoriert, wenn wichtige Teile mit Zeichenfolgen verglichen werden.

Ich mache mir nur Sorgen, dass diese Änderung zu groß sein wird

Natürlich ist es eine große Veränderung, aber es wird zukünftige bahnbrechende Veränderungen reduzieren.

wir werden es nicht beenden können

Nun, das hängt ganz von der Frist ab ...

Wie bereits erwähnt, sollten wir dieses Problem eher vergessen (Vorbehalt von Sonderzeichen). Stattdessen sollten Escape-Aktionen auf höherer Ebene (wie Arrays # , % ) oder Reservierungen von Sonderzeichen ( @ ) direkt in den Speicher-Plugins erfolgen.

Nun, das hängt ganz von der Frist ab ...

Wenn Sie eine Masterarbeit über zukunftssichere Softwarebibliotheken erstellen möchten, können Sie dieses Thema erneut öffnen: wink:

Wie besprochen [...]

Daran erinnere ich mich nicht aus der Diskussion. Ich dachte, wir waren uns einig, # 3115 zu beenden und dann noch einmal über dieses Problem nachzudenken.

Ich werde # 3115 beenden und dem Vorschlag auch einige Beispiele und einfache englische Erklärungen hinzufügen.

Stattdessen sollte das Escaping auf höherer Ebene (wie Arrays #,%) oder das Reservieren von Sonderzeichen (@) direkt in den Speicher-Plugins erfolgen.

Dies ist ehrlich gesagt eine dumme Lösung ...

Jedes Mal, wenn wir Schlüsselnamen etwas Neues hinzufügen, müssen wir alle Speicher-Plugins aktualisieren. Das ist genau der Grund, den Sie gegen meine Lösung verwendet haben (was dies nur einmal erfordert).

Es wird auch nicht vermieden, die Plugins jetzt zu aktualisieren, da AFAIK keines von ihnen tatsächlich 100% korrekte Schlüsselnamen (Array-Teile) verarbeitet.

Wenn Sie meinen Vorschlag wirklich nicht wollen, geben Sie bitte einen Grund dagegen an, anstatt eine Lösung vorzuschlagen, die nichts löst und fast genauso viel Aufwand bedeutet.

Wenn Sie eine Masterarbeit über zukunftssichere Softwarebibliotheken machen möchten

Nein, das möchte ich nicht tun ... Ich möchte nur die Schlüsselnamen von Electra zukunftssicher machen, was eine viel kleinere und einfachere Aufgabe ist.

Daran erinnere ich mich nicht aus der Diskussion. Ich dachte, wir waren uns einig, # 3115 zu beenden und dann noch einmal über dieses Problem nachzudenken.

Ja, wir haben die Diskussion nicht beendet, aber:

• Meine Empfehlung ist, andere wichtige Fehler und Usability-Probleme zu beheben.
• Ich kann und will dir sowieso nicht verbieten, darüber nachzudenken: zwinker:

Es wird auch nicht vermieden, die Plugins jetzt zu aktualisieren, da AFAIK keines von ihnen tatsächlich 100% korrekte Schlüsselnamen (Array-Teile) verarbeitet.

Bitte melden Sie Fehler. Die Verwendung von Arrays gemäß doc / entscheidungen / array.md sollte korrekt sein. Dann ist #0 ein "einfacher Name ohne Bedeutung" und Arrays erhalten nur eine Bedeutung mit einem Schlüssel direkt darunter, der Metadaten "Array" enthält.

Wenn Sie meinen Vorschlag wirklich nicht wollen, geben Sie bitte einen Grund dagegen an.

Ich mag den Vorschlag sehr. Aber Dinge wie # 1074 (und siehe https://github.com/ElektraInitiative/libelektra/projects/9 für mehr) sind meiner Meinung nach viel kritischer für den Erfolg von Elektra.

anstatt eine Lösung vorzuschlagen, die nichts löst und fast genauso viel Aufwand bedeutet.

Was meinst du? Mein letzter Vorschlag war, einfach keine Zeichen zu reservieren und es den Speicher-Plugins zu überlassen, das zu tun, was sie wollen. Ich sehe keine Anstrengungen bei der "Umsetzung" dieses Vorschlags (es ist ein NOP).

Nein, das möchte ich nicht tun ... Ich möchte nur die Schlüsselnamen von Electra zukunftssicher machen, was eine viel kleinere und einfachere Aufgabe ist.

Vielleicht reicht das schon für eine Masterarbeit, wenn Sie die Beweise fertig haben. Ich habe mich aber nicht mit verwandten Arbeiten befasst, vielleicht hat schon jemand anderes so etwas gemacht.

Die Verwendung von Arrays gemäß doc / entscheidungen / array.md sollte korrekt sein.

Das mag der Fall sein, aber das Tutorial für Speicher-Plugins ist anderer Meinung und zeigt sogar, dass yamlcpp auf diese Weise nicht funktioniert.

Aber Dinge wie # 1074 sind meiner Meinung nach viel kritischer für den Erfolg von Elektra.

Ich befasse mich mit Änderungen an Schlüsselnamen, denn das ist es, was ich bereits mache und ich habe gerade viel Einsicht. Darüber hinaus haben wir bereits eine bahnbrechende Änderung der Schlüsselnamen, sodass es nicht so wichtig ist, wenn wir mehr Dinge brechen.

Die User / Dir-Mountpunkte wären ja nett, aber ich habe keine Ahnung, wie ich das lösen soll. Ich würde wahrscheinlich genauso lange oder länger brauchen, um eine Lösung zu finden und zu implementieren, wie ich brauchen würde, um meine vorgeschlagenen Änderungen an Schlüsselnamen zu implementieren.

Mein letzter Vorschlag war, einfach keine Zeichen zu reservieren

Sie haben erwähnt, dass Sie @ reservieren.

Überlassen Sie es den Speicher-Plugins, das zu tun, was sie wollen

Das führt nur zu Inkompatibilitäten. Natürlich können wir nicht verhindern, dass Speicher-Plugins ein völlig anderes Format verwenden, aber wenn wir keine Richtlinien angeben, werden wir nur nach Problemen fragen.

Das mag der Fall sein, aber das Tutorial für Speicher-Plugins ist anderer Meinung und zeigt sogar, dass yamlcpp nicht so funktioniert.

@sanssecours kannst du das untersuchen? Wenn wir Arrays nur aufgrund der Struktur erkennen (Namen mit #0 ), wird das KeySet kein Round-Tip geben.

Ich würde wahrscheinlich genauso lange oder länger brauchen, um eine Lösung zu finden und umzusetzen

Ja, aber User / Dir-Mountpoint ist etwas, mit dem jeder Elektra-Benutzer häufig konfrontiert wird. Ob wir jemals reservierte Zeichen benötigen, ist nicht bekannt.

Sie haben erwähnt, dass Sie @ reservieren.

Ja, Speicher-Plugins können reservieren und entkommen, was sie wollen.

Das führt nur zu Inkompatibilitäten. Natürlich können wir nicht verhindern, dass Speicher-Plugins ein völlig anderes Format verwenden, aber wenn wir keine Richtlinien angeben, werden wir nur nach Problemen fragen.

Ich stimme vollkommen zu. Vielleicht hassen uns einige Leute in einigen Jahren dafür, dass wir einige Charaktere nicht reserviert haben (aber vielleicht auch nicht). Ich bin mir jedoch ziemlich sicher, dass dies nicht zum Erfolg von Elektra 1.0 beitragen wird. Um es klar auszudrücken: Ich bin absolut nicht gegen die Implementierung, aber andere Dinge (https://github.com/ElektraInitiative/libelektra/projects/9) stehen meiner Meinung nach viel höher in der Prioritätenliste. Es steht Ihnen frei, nicht zuzustimmen und es trotzdem umzusetzen. Ich würde die PR nicht ablehnen, solange sie für Speicher-Plugins nicht zu kompliziert wird (und alle Plugins repariert werden). Aber es besteht ein hohes Risiko , dass andere Sachen (die für den Erfolg notwendig ist) nicht erhalten implementiert und Elektra nicht in wichtigen Projekten wie KDE verwendet werden.

@sanssecours kannst du das untersuchen? Wenn wir Arrays nur aufgrund der Struktur erkennen (Namen mit #0 ), wird das KeySet kein Round-Tip geben.

Ich habe das Verhalten von YAML CPP und des Verzeichniswert-Plugins in PR 3357 aktualisiert. Die Pull-Anforderung aktualisiert auch einen Teil der Dokumentation, um die obligatorischen array -Metadaten zu berücksichtigen.

Ich habe den Vorschlag jetzt in # 3447 aktualisiert. Ich hoffe es ist jetzt leichter zu verstehen (es ist noch sehr lang).

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

@ markus2330 Ich werde dies hier

Ich habe gerade entdeckt / mich daran erinnert, dass es in der aktuellen Version von Elektra [1] bereits so ist (und auf diese Weise implementiert wurde), dass "jeder ESCAPED- Schlüsselname-Teil, der mit @ beginnt, den gesamten Schlüssel ungültig macht". Dies bedeutet, dass wir - ohne die anderen Änderungen des Vorschlags zu implementieren - Feldnamen, die mit @ für spezielle Zwecke in Speicher-Plugins verwenden können, wie der Vorschlag mit $meta und $value vorschlägt

@ bauhaus93 Dies kann Ihnen helfen, wenn Sie Metadaten in toml implementieren (und in gewissem Umfang auch für Schlüssel ohne Blattwert).

Für diejenigen, die den Vorschlag nicht gelesen haben, wäre die Idee im Wesentlichen (für JSON):

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

Verwandelt sich in zwei Schlüssel:

key = 127.0.0.1
key/sub = xyz

und key hat auch diese Metadaten:

check/ipaddr = ipv4

~ Da sowohl key/@value als auch key/@meta reservierte Schlüsselnamen sind (oder in # 3447 sogar ungültig sind), kann dies keine Konflikte verursachen. ~

[1] master erwähnt dies nur in der Dokumentation , lässt Sie jedoch solche Schlüssel erstellen. # 3447 andererseits ~ verbietet diese Schlüssel vollständig ~ erfordert, dass @ am Anfang von Schlüsselnamen-Teilen in maskierten Schlüsselnamen maskiert wird. Die Dokumentation enthält auch eine ähnliche Bestimmung für _ , die jedoch auch in # 3447 nicht durchgesetzt wird.

Entschuldigen Sie die Verwirrung, aber ich musste Teile des obigen Kommentars klarstellen. Der Teil über @ gilt nur für den maskierten Schlüsselnamen. Der nicht entkoppelte Name (als C-String) "\01\00key\00@meta\00" ist in # 3447 weiterhin gültig, wie es jemals war. Dies bedeutet, dass @meta nicht ohne weitere Überlegungen im Speicher-Plugin für Metadaten verwendet werden

Da es sich jedoch immer um einen reservierten Namen handelte und wir die Flucht in # 3447 benötigen, halte ich es immer noch für fair, ihn in einem Speicher-Plugin zu verwenden. IMO sollte ein Benutzer nicht erwarten, dass ein reservierter Name immer ohne Probleme verwendet werden kann. Aber natürlich müssen wir einige Vorsichtsmaßnahmen treffen. Eine Möglichkeit wäre dies (wieder JSON):

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

Verwandelt sich in zwei Schlüssel (beachten Sie die \ für die Flucht):

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

Aber dieses

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

Wird zu (wieder \ für die Flucht):

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

Die Regeln hier wären:

• Der Feldname beginnt nicht mit einem @ -> Verwenden Sie den Feldnamen und fügen Sie ihn mit keyAddBaseName
• Der Feldname beginnt mit mehr als einem @ -> Entfernen Sie ein erstes @ und verwenden Sie den Rest für keyAddBaseName
• Der Feldname beginnt mit einem einzelnen @ -> Überprüfen Sie, ob der Feldname eine besondere Bedeutung hat (z. B. @value oder @meta ):
  
  
  
  • Wenn es eine besondere Bedeutung hat, verarbeiten Sie es entsprechend
  
  
  • Andernfalls verwenden Sie einfach den Feldnamen für keyAddBaseName (z. B. @sub ).
  
  

(Hinweis: keyAddBaseName einen nicht entkoppelten Namen und führt die erforderliche Escape-Zeichenfolge aus, um den Schlüsselnamen gültig zu halten.)

Ich verstehe das Ziel der letzten beiden Kommentare nicht. Ist dies ein Vorschlag zum Ersetzen des Verzeichniswert-Plugins?

(Beachten Sie das \ für die Flucht)

Für @ wir normalerweise @ für die Flucht verwendet, um einfach die ersten @ zu verwerfen, wenn es mehrere gibt. Wäre gut, wenn dies auch in der Beschreibung des Schlüsselnamens dokumentiert ist. Wir könnten zu \ wechseln (wenn dies das Escapezeichen für Schlüsselnamen im Allgemeinen verständlicher macht), aber dies erfordert Änderungen zumindest im base64-Plugin. (Null Plugin wird in # 3491 gelöscht)

Ich verstehe das Ziel der letzten beiden Kommentare nicht. Ist dies ein Vorschlag zum Ersetzen des Verzeichniswert-Plugins?

Der @value Teil ist ja. Aber es ist allgemeiner. @meta kann zum Speichern von Metadaten in einem Format mit einer einzelnen verschachtelten Objektstruktur wie JSON oder TOML verwendet werden (immer noch nicht sicher über YAML, da Tags).
Grundsätzlich gibt es keinen Platz zum Speichern von Metadaten, da sich alles in der JSON-Datei auf einen Schlüssel bezieht. Es sei denn, Sie legen der Struktur der JSON-Datei einige Einschränkungen auf, aber dann können Sie wahrscheinlich nicht einfach eine Konfigurationsdatei bereitstellen. [1]

Wie gesagt, Sie müssen Einschränkungen auferlegen, um Metadaten in JSON anzupassen (AFAIK gilt auch für TOML). Ja, mein Vorschlag in den obigen Kommentaren führt zu einer Einschränkung der JSON-Dateien, aber Anwendungen, die @ am Anfang eines JSON-Felds verwenden, sind wahrscheinlich ziemlich selten.

Für @ haben wir normalerweise @ für die Flucht verwendet, um einfach das erste @ zu verwerfen, wenn es mehrere gibt. Wäre gut, wenn dies auch in der Beschreibung des Schlüsselnamens dokumentiert ist. Wir könnten zu \ wechseln (wenn dies das Escapezeichen für Schlüsselnamen im Allgemeinen verständlicher macht), aber dies erfordert Änderungen zumindest im base64-Plugin.

Ich bin mir nicht sicher, wie das base64 Plugin hier relevant ist, aber ich möchte ganz klar sagen:

Auf dem aktuellen master (6a1535c094c7be2f441bd0e7b0dda1c50e97ee1d) funktioniert keyNew ("/elektra/@abc", KEY_END) und erstellt einen nicht entkoppelten Namen mit den Teilen elektra und @abc .
In # 3447 gibt keyNew ("/elektra/@abc", KEY_END) NULL da der Name als ungültig angesehen wird, aber keyNew ("/elektra/\@abc", KEY_END) funktioniert und einen nicht entkoppelten Namen mit den Teilen elektra und @abc .
Ich bin mir nicht sicher, was keyNew ("/elektra/\@abc", KEY_END) auf dem Master macht.

keyAddBaseName (k, "@abc") funktioniert in beiden Fällen. Der einzige Unterschied besteht darin, welcher Escape-Name erstellt wird.

Ich erinnere mich auch nicht, warum ich diese Änderung vorgenommen habe. Es gab wahrscheinlich einen guten Grund, aber auf jeden Fall ist es jetzt erledigt und ich denke nicht, dass es einfach wäre, zurück zu wechseln.

[1] Wie immer besteht das Problem hier darin, dass Elektra alles tun und allen gefallen will. Einerseits möchten wir Speicher-Plugins zulassen, die beliebige Dateien in einem Standardformat (z. B. JSON) lesen und in KeySets umwandeln können. Andererseits möchten wir Anwendungen erlauben, beliebige Zeichenfolgen als Teil eines Schlüsselnamens zu verwenden. Dies mag einige Zeit funktionieren, aber zumindest wenn Sie zu Metadaten gelangen, wird es für bestimmte Formate unterbrochen.

JSON ist ein einzelner Baum mit Werten nur an den Blattknoten. KeySets sind ein Baum mit Werten an jedem Knoten, und einige der Knoten haben auch eine Verknüpfung zu einem ganzen separaten Baum. Möglicherweise können Sie zwischen den beiden konvertieren, aber einer von ihnen muss dem anderen Einschränkungen auferlegen, um eine verlustfreie Konvertierung zu erzielen.

Wie gesagt, Sie müssen Einschränkungen auferlegen, um Metadaten anzupassen

@kodebach bedeutet dies, dass Sie dafür sind, die Formate einzuschränken, in denen Metadaten gespeichert werden können?

Ich bin nie darauf gestoßen, weil ich meistens dump und dann mmapstorage verwendet habe und nur selten Konfigurationen mit anderen Plugins importiert / exportiert habe. Das ist ziemlich unglücklich. Als Benutzer wäre ich eher in der Lage, in Standardspezifikationen zu importieren / exportieren (Metadaten zu verlieren), während ich die realen Daten (einschließlich Metadaten) in einem beliebigen internen elektra-internen Format speichere.

Ich denke, die Einschränkung des Formats könnte für Benutzer verwirrend sein. Wenn Elektra beispielsweise ein nicht experimentelles JSON-Plugin bereitstellt, würde ich erwarten, dass es beliebige spezifikationskonforme Eingaben verarbeiten kann. Mir ist unklar, wie der Benutzer überprüfen kann, ob seine Konfigurationsdateien der eingeschränkten Spezifikation entsprechen.

@ markus2330 Was denkst du über das Auferlegen von Einschränkungen für das Format?

EDIT: Ich stimme zu, dass "Elektra alles tun und allen gefallen will" ein Problem ist.

Bedeutet dies, dass Sie dafür sind, die Formate einzuschränken, in denen Metadaten gespeichert werden können?

Wir müssen unsere Prioritäten definieren. Was genau ist ein absolutes Muss und wo können sich die Dinge ändern. Derzeit besteht die einzige Möglichkeit für viele Formate darin, Metadaten in Kommentaren zu speichern ( keine Lösung, sondern nur eine klobige Lösung. Das Schlimmste ist, dass der eine Teil missbraucht wird, der niemals von einem Parser berührt werden sollte und die Lesbarkeit einer Speicherdatei drastisch beeinträchtigen kann. Einige Formate (nämlich JSON) haben auch keine Kommentare.

Sehr grundlegende Einschränkungen, die wir auferlegen könnten (am Beispiel von JSON), wären, dass alle Dateien so aussehen müssen:

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

Andere "Einschränkungen" umfassen das Interpretieren bestimmter Schlüsselnamen wie @meta auf spezielle Weise und das Bereitstellen von Escape-Methoden.

Das kdb -Objekt enthält die tatsächlichen Schlüssel und meta enthält die Metadaten. (Hinweis: Um Nicht-Blatt-Schlüssel mit Werten zu lösen, benötigen Sie ein anderes Objekt.)

Anstelle von zwei JSON-Objekten können auch separate Dateien verwendet werden. Aber das würde zumindest Unterstützung vom Resolver und vielleicht sogar vom Backend-Code / Plugin benötigen. Separate Dateien würden es ermöglichen, Standard-JSON-Dateien ohne Metadaten zu importieren. Wie Nicht-Blatt-Schlüssel mit Werten in diesem Fall behandelt werden, ist nicht klar.

Als Benutzer wäre ich eher in der Lage, in Standardspezifikationen zu importieren / exportieren (Metadaten zu verlieren), während ich die realen Daten (einschließlich Metadaten) in einem beliebigen internen elektra-internen Format speichere.

Ich stimme zu, aber das Importieren / Exportieren von allem widerspricht ein wenig der Mountpoint-Idee von Elektra.

Ich weiß bereits, niemand möchte dies umsetzen, aber es gibt eine sehr allgemeine Lösung:

Wenn ein Mountpoint ein Speicher-Plugin verwendet, das nicht alle Funktionen von Elektra unterstützt, erstellt das Backend-Plugin eine sekundäre Fallback-Speicherdatei in einem Format, das alle Funktionen unterstützt (z. B. quickdump , mmapstorage scheint hier eine Verschwendung von Speicherplatz zu sein). Wenn wir einen solchen Mountpoint schreiben, schreiben wir einfach mit beiden Plugins. Beim Lesen lesen wir zuerst die sekundäre Fallback-Datei und dann die primäre Datei. Dies würde einen Zusammenführungsprozess erfordern, aber wir werden die Primärdatei als Durchgangsquelle verwenden, so dass die Zusammenführung recht einfach ist.

Ich denke, die Einschränkung des Formats könnte für Benutzer verwirrend sein.

Bestimmt. Aber mir ist klar, dass Elektra derzeit zu viel erlaubt und etwas eingeschränkt werden muss.

Selbst die Lösung mit mehreren Dateien erfordert eine Einschränkung der Konfiguration von Dateinamen, um Kollisionen zu vermeiden.

Ursprünglich dachte ich, die einfachste Lösung wäre, Elektras Schlüsselnamen einzuschränken, da dies der Teil ist, über den wir die größte Autorität haben. Aber anscheinend gibt es Anwendungen, die WiFi-SSIDs [1] direkt als Schlüsselnamen verwenden, sodass dies nicht funktioniert. Zumindest nicht ohne großen Aufwand, wie mein Vorschlag zeigte ...
IMO wäre es immer noch die beste Lösung für all dies, einfach zu sagen "Key Name Parts sind keine willkürlichen Sequenzen von Nicht-Null-Bytes mehr " und damit fertig zu werden. Zum Vergleich erlaubt POSIX nur die folgenden Zeichen in Dateinamen:

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 . _ -

Und das scheint für die Menschen genug zu sein. Alle auf Wikipedia aufgelisteten Dateisysteme (mit Ausnahme derjenigen ohne Verzeichnisse) unterliegen einer gewissen Einschränkung der Dateinamen.

Ich möchte noch einmal betonen: All dies läuft darauf hinaus, dass wir "Schlüsselnamen-Teile sind willkürliche Folgen von Nicht-Null-Bytes" als Axiom genommen haben [2]. Dies zu ändern wäre sehr einfach und würde alles reparieren. Es könnte sogar eine kleine Einschränkung zB „Schlüsselname Teile sind beliebige Sequenzen von Nicht-Null - Bytes, mit Ausnahme diejenigen , dass beide beginnen mit seinem @$% und Ende in !%& zur gleichen Zeit“.
Nur ein einzelnes Key Name Part zu reservieren, z. B. "Key Name Parts sind willkürliche Folgen von Bytes ungleich Null, außer !@& ist nicht", würde uns viele Möglichkeiten bieten. Heck, auch die Einschränkung "der letzte Schlüsselname Teil in einem Schlüsselnamen darf nicht mit @%& enden" sollte ausreichen. Jede Art von Einschränkung [3], egal wie klein sie ist, würde uns Spielraum für die Umsetzung aller möglichen Dinge geben.
Natürlich ermöglichen viele Einschränkungen Lösungen, aber für eine gute und brauchbare Lösung sind möglicherweise größere Einschränkungen erforderlich.

Tut mir leid, wenn dies wie ein Scherz erscheint, aber irgendwann wird es wirklich frustrierend, dass alle zustimmen, dass es ein Problem gibt, aber jede Lösung als fehlerhaft angesehen wird oder als zu kompliziert angesehen wird.

[1] Laut Wikipedia war eine WiFi-SSID bis zum 802.11-2012 "null bis 32 Oktette (32 Byte) lang", einschließlich null Byte, und "drahtlose Netzwerkstapel müssen noch darauf vorbereitet sein, beliebige Werte im SSID-Feld zu verarbeiten" obwohl SSIDs jetzt UTF-8 gültig sein müssen. Nur keyAddBaseName einer WiFi-SSID ohne zusätzliche Logik wären ohnehin nicht standardkonform.

[2] Aus diesem Grund beginnt die neue Dokumentation in # 3447 mit Key Name Parts. Es ist am einfachsten (und IMO am logischsten), die aktuellen Schlüsselnamen zu erklären, indem Sie mit Schlüsselnamen beginnen und von dort fortfahren. Aber die alte Art von

Nehmen Sie einen Unix / POSIX-Dateisystempfad und fügen Sie einen Namespace hinzu, aber es gibt auch etwas Besonderes wie leere Teile und Escape-Sequenzen, und dann gibt es die nicht entflohene Version - sie ist halb versteckt, sollte aber wahrscheinlich für alles verwendet werden außer Drucken - oh, und Arrays sind eine Sache, auch einige Teile sind reserviert, aber nicht reserviert, so dass wir sie nicht für irgendetwas auf niedriger Ebene verwenden, ....

zeigt viel besser, wie wahnsinnig komplex und kompliziert Schlüsselnamen sind.

[3] Falls Sie sich fragen, ja, # 3447 legt einige neue Einschränkungen fest, aber diese sind nutzlos, da sie den Namen des nicht entschlüsselten Schlüssels (mit Ausnahme des Namespace) in keiner Weise beeinflussen.

Separate Dateien würden es ermöglichen, Standard-JSON-Dateien ohne Metadaten zu importieren. Wie Nicht-Blatt-Schlüssel mit Werten in diesem Fall behandelt werden, ist nicht klar.

Wir haben dies bezüglich der Cache-Implementierung diskutiert und uns dagegen entschieden. Die aktuelle Implementierung des Resolvers bietet stärkere Konsistenzgarantien als bei Verwendung von zwei Dateien. Der Resolver verwendet die atomare Funktion rename() , um sicherzustellen, dass ein Prozess entweder die alte oder die neue Datei liest, aber immer eine konsistente. Leider kann dies (meines Wissens) nicht mit mehreren Dateien bei gleichen Garantien durchgeführt werden. Ich würde nur ungern mehrere Dateien verwenden, bei denen wir die Konsistenz sicherstellen müssen.

Ich stimme zu, aber das Importieren / Exportieren von allem widerspricht ein wenig der Mountpoint-Idee von Elektra.

Wahr.

All dies läuft darauf hinaus, dass wir "Key Name Parts sind willkürliche Folgen von Bytes ungleich Null" als Axiom genommen haben [2].

Ich stimme zu, dies ist der Teil, in dem Einschränkungen am sinnvollsten sind. Wie Sie gesagt haben, sind Dateinamen ziemlich eingeschränkt und es funktioniert immer noch sehr gut. Es sei denn, jemand kennt einen guten Grund, Schlüsselnamen nicht einzuschränken (vielleicht @ markus2330)?

Entschuldigung, wenn dies wie ein Scherz erscheint

Nein, und danke, dass Sie darüber gesprochen haben. Sofern @ markus2330 einige Gründe nicht kennt, warum wir dies nicht ändern können, bin ich offen für Ihren Vorschlag (z. B. die Einschränkung von !@& ).

Ich würde nur ungern mehrere Dateien verwenden, bei denen wir die Konsistenz sicherstellen müssen.

Das ist ein guter Grund, gegen mehrere Dateien ja ...

Ich bin völlig offen für Ihren Vorschlag (wie die Einschränkung von !@& ).

Realistischer könnten wir die Einschränkung auferlegen: "Ein Schlüsselname darf nicht den Schlüsselnamen Teil @elektra " (möglicherweise ein dunkleres Präfix, wenn dies hilft). Ich denke, die Verwendung von elektra könnte das Ganze für Benutzer ein bisschen vernünftiger machen.

Persönlich denke ich, wir sollten Platz für die Zukunft lassen, aber wenn die Einschränkung aller Schlüsselnamen zu groß ist, können wir auch einschränken, was kdbGet kann und was kdbSet akzeptieren kann. Die obige Einschränkung würde also nur für das gelten, was das letzte Plugin während kdbGet zurückgibt, und für das KeySet das kdbSet . Grundsätzlich würden wir nur einschränken, welche Schlüssel aus Sicht einer Anwendung gespeichert werden können. Dies ähnelt dem, was wir bereits mit system:/elektra (obwohl wir diesmal die Einschränkung tatsächlich durchsetzen würden).

Vielen Dank für diese wertvollen Diskussionen. Ich begann # 3514, um die wichtigen Entscheidungen zusammenzufassen, die überall verstreut sind. Bitte kommentieren Sie den Text in # 3514 lieber direkt, damit wir zu Schlussfolgerungen kommen können.

Der @ value- Teil ist yes. Aber es ist allgemeiner. @meta kann zum Speichern von Metadaten in einem Format mit einer einzelnen verschachtelten Objektstruktur wie JSON oder TOML verwendet werden (bei YAML immer noch nicht sicher, da Tags).
Grundsätzlich gibt es keinen Platz zum Speichern von Metadaten, da sich alles in der JSON-Datei auf einen Schlüssel bezieht.

Ich denke nicht mehr, dass es unser Ziel sein sollte, Einschränkungen von Dateiformaten zu umgehen. Wenn JSON keine Metadaten und Nicht-Blattwerte unterstützt, leitet Elektra mit einer gemounteten JSON-Datei einfach die Einschränkungen für KeySets weiter. Wir können sie dokumentieren, wie in # 3504 vorgeschlagen, und die Speicher-Plugins sollten auf solchen KeySets fehlschlagen, aber nicht mehr. (Natürlich kann jemand mit weniger Einschränkungen ein Super-JSON-Dateiformat entwickeln, aber dies liegt außerhalb unserer derzeitigen Arbeitskraft und ist als solches irrelevant.)

Anwendungen, die @ am Anfang eines JSON-Felds verwenden, sind jedoch wahrscheinlich ziemlich selten.

Wer weiß?

keyAddBaseName (k, "@abc") funktioniert in beiden Fällen. Der einzige Unterschied besteht darin, welcher Escape-Name erstellt wird.

Hört sich gut an.

Aber zumindest wenn Sie zu Metadaten gelangen, werden diese für bestimmte Formate unterbrochen.

Ja, wir müssen die Idee fallen lassen, dass jedes Format alles unterstützen kann.

Mir ist unklar, wie der Benutzer überprüfen kann, ob seine Konfigurationsdateien der eingeschränkten Spezifikation entsprechen.

Ich denke, dass die meisten Anwendungen sowieso nicht sehr anspruchsvoll sein werden (z. B. nur Blattwerte haben und keine Metadaten außer Typ benötigen), daher ist alles, was wir hier diskutieren, nur für außergewöhnliche Anwendungen relevant. Für diese Anwendungen halte ich es für das Beste, dass Anwendungsentwickler ihre eigenen Speicher-Plugins entwickeln oder unsere besten Speicher-Plugins verwenden, die solche Dinge unterstützen.

@ markus2330 Was denkst du über das Auferlegen von Einschränkungen für das Format?

Das ist keine gute Idee. Wir sollten standardisierte Konfigurationsdateiformate unterstützen. Es kann ein großes Problem sein, wenn einige gültige JSON / XML-Dateien von Elektra abgelehnt werden. Andererseits müssen wir nichts weiter als standardisiert unterstützen. Dies zu versuchen war ein Fehler aus der Vergangenheit (zu versuchen, irgendjemandem zu gefallen).

Wir müssen unsere Prioritäten definieren. Was genau ist ein absolutes Muss und wo können sich die Dinge ändern.

doc / GOALS.md in # 3514

Das Schlimmste ist, dass der eine Teil missbraucht wird, der niemals von einem Parser berührt werden sollte und die Lesbarkeit einer Speicherdatei drastisch beeinträchtigen kann.

Ich bin damit einverstanden, dass es nicht die beste Idee ist, es gab bereits viele Probleme im ini Plugin. badcec5407df6947a67750afd8f0946245c5a5bb

Anstelle von zwei JSON-Objekten können auch separate Dateien verwendet werden.

Siehe unten.

Zum Vergleich erlaubt POSIX nur die folgenden Zeichen in Dateinamen:

Dies ist der "tragbare Dateinamen-Zeichensatz", und ich bezweifle, dass mehr ein Dateisystem verwendet wird, das dies nur unterstützt. Nach meiner Erfahrung führt jede Interpretation der Dateinamen nur zu Problemen (z. B. hatte JFS solche Funktionen).

Und das scheint für die Menschen genug zu sein.

Für Elektras Quelle ist es fast # 1615: wink:

Aber echte Anwendungen wollten sofort mehr ... (zB Leerzeichen, Umlaute, ....)

Dies zu ändern wäre sehr einfach und würde alles reparieren.

So einfach ist das nicht: Es macht Speicher-Plugins viel komplizierter. Es verschiebt die Logik einfach an andere Orte.

außer denen, die beide mit @ $% beginnen und gleichzeitig mit!% & enden

Diese Idee ähnelt CDATA . Es ist keine schöne Lösung und unhandlich in der Praxis zu verwenden.

HERE Dokumente sind etwas besser, da der Benutzer die Escape-Sequenz definieren kann.

Aber für welche Funktion genau brauchen wir sie Ihrer Meinung nach? Ich denke, wir sollten diese Funktionen lieber vergessen und Metadaten richtig verwenden, um Schlüsseln Semantik zu verleihen.

Tut mir leid, wenn dies wie ein Scherz erscheint, aber irgendwann wird es wirklich frustrierend, dass alle zustimmen, dass es ein Problem gibt, aber jede Lösung als fehlerhaft angesehen wird oder als zu kompliziert angesehen wird.

Mein Punkt ist: Vielleicht brauchen wir keine Lösung, weil das Problem nicht existiert.

muss jetzt UTF-8 gültig sein

Können sie noch Nullzeichen haben? Übrigens. Ich habe mir das SSID-Beispiel ausgedacht, weil dies eine echte Anforderung eines echten Kunden (Broadcom) war. Nullzeichen waren nicht erforderlich, es ist offensichtlich, dass ein char* ohne Größe dies nicht unterstützen kann, daher haben wir nicht einmal darüber gesprochen.

zeigt viel besser, wie wahnsinnig komplex und kompliziert Schlüsselnamen sind.

Ja, aber besser sind sie so, als eine solche Logik in jeder Anwendung und jedem Speicher-Plugin zu haben.

Falls Sie sich fragen, ja, # 3447 legt eine neue Einschränkung fest

Ja, der Schlüsselname kann Einschränkungen unterliegen. Es gab immer die Einschränkung der baumelnden Flucht, so dass ein paar weitere Einschränkungen keine Rolle spielen. # 3447 wird eine enorme Verbesserung für Elektra sein.

Leider kann dies (meines Wissens) nicht mit mehreren Dateien bei gleichen Garantien durchgeführt werden

Sie können dazu ein Journalprotokoll schreiben, in das Sie alles schreiben, was Sie vorhaben, und bei Problemen Probleme beheben, indem Sie das Journal erneut abspielen. Dies umzusetzen ist weit über unsere menschliche Kraft hinaus. Es passt auch nicht wirklich zu einem Konfigurationssystem (oder Dateisystemen), es ist eine Technik für strukturierte Datenbanken.

Ich habe es in multiple_file_backends.md zu einem Nicht-Ziel gemacht. 59066aa99bae707d0f0178841513fd3b8590b5bc

Grundsätzlich würden wir nur einschränken, welche Schlüssel aus Sicht einer Anwendung gespeichert werden können. Dies ähnelt dem, was wir bereits mit system: / elektra haben (obwohl wir diesmal die Einschränkung tatsächlich durchsetzen würden).

Wir können die Einschränkung von system:/elektra . Aber warum möchten Sie einschränken, welche Anwendungen in ihrem Teil ihrer Hierarchie gespeichert werden?

Ich denke, es ist am besten, wenn Anwendungsentwickler ihre eigenen Speicher-Plugins entwickeln

Damit wird einer der Hauptvorteile von Elektra besiegt: "Der Administrator / Benutzer entscheidet über das Konfigurationsformat, nicht über den Anwendungsentwickler."

Es kann ein großes Problem sein, wenn einige gültige JSON / XML-Dateien von Elektra abgelehnt werden

Das war nie mein Vorschlag. Natürlich sollten wir jeden gültigen JSON akzeptieren. Die Frage ist, welche KeySet wir produzieren. Wenn wir "@value" für Nicht-Blatt-Werte verwenden, wie oben vorgeschlagen, können wir trotzdem jeden gültigen JSON akzeptieren. Das resultierende KeySet manchmal nur eine etwas andere Struktur.

Zum Vergleich erlaubt POSIX nur die folgenden Zeichen in Dateinamen:

Dies ist der "tragbare Dateinamen-Zeichensatz", und ich bezweifle, dass mehr ein Dateisystem verwendet wird, das dies nur unterstützt. Nach meiner Erfahrung führt jede Interpretation der Dateinamen nur zu Problemen (z. B. hatte JFS solche Funktionen).

Und das scheint für die Menschen genug zu sein.

Für Elektras Quelle ist es fast # 1615

Aber echte Anwendungen wollten sofort mehr ... (zB Leerzeichen, Umlaute, ....)

Sie erlauben immer noch keine / oder leere Namen. Die meisten haben auch maximale Längen für Dateinamen und Pfade. Der Punkt ist, dass Anwendungen Wege finden, um Einschränkungen zu umgehen. Und in unserem Fall können wir ihnen sogar mit Bibliotheken helfen.

So einfach ist das nicht: Es macht Speicher-Plugins viel komplizierter. Es verschiebt die Logik einfach an andere Orte.

Ich stimme nicht zu. Speicher-Plugins sind bereits äußerst komplex, relativ gesehen wäre dies nur eine geringfügige Unannehmlichkeit. (vorausgesetzt, wir bieten eine gute storage Bibliothek mit Hilfsfunktionen)

Diese Idee ähnelt CDATA. Es ist keine schöne Lösung und unhandlich in der Praxis zu verwenden.

HIER sind Dokumente etwas besser, da der Benutzer die Escape-Sequenz definieren kann.

Sowohl CDATA als auch HERE Dokumente müssen eine Syntax reservieren, aus Elektras aktueller Sicht gibt es keinen Unterschied. Beide Versionen sind eine Einschränkung für Schlüsselnamen.

Auch sind beide viel mächtiger als das, was ich vorgeschlagen habe. Mein Vorschlag würde jeweils nur einem vollständigen Schlüsselnamen-Teil "entkommen".

Ich denke, wir sollten diese Funktionen lieber vergessen und Metadaten richtig verwenden, um Schlüsseln Semantik zu verleihen.

Sie haben gerade gesagt, dass einige Speicher-Plugins möglicherweise keine Metadaten unterstützen. Es scheint also, dass dies keine Option ist.

Mein Punkt ist: Vielleicht brauchen wir keine Lösung, weil das Problem nicht existiert.

Wenn Sie nur Ihre Meinung ändern und sagen, dass ein Speicherformat die Fähigkeiten von Elektra einschränken kann, verschwindet das Problem natürlich. Dies ändert jedoch grundlegend das Versprechen von Elektra an die Benutzer. Wir würden alle Benutzer einschränken, nur um es einigen Entwicklern zu ermöglichen, einige Codezeilen zu speichern, die sich mit der Codierung spezieller Werte befassen.

Können sie noch Nullzeichen haben?

Wahrscheinlich ist NUL ein gültiges UTF-8-Zeichen.

ohne Größe kann dies nicht unterstützen

Nun, die maximale Größe einer SSID beträgt 32 Bytes, sodass Sie die Größe nicht übergeben müssen, solange der Puffer immer 32 Bytes groß und mit Nullen aufgefüllt ist.

Ja, der Schlüsselname kann Einschränkungen unterliegen.

Bitte entscheiden Sie sich. Diese ganze Zeit Sie haben argumentiert , dass es keine Einschränkungen geben

Es gab immer die Einschränkung der baumelnden Flucht, so dass ein paar weitere Einschränkungen keine Rolle spielen.

"Dangling Escape" ist keine Einschränkung. Es handelt sich um einen Syntaxfehler im Namen des Escape-Schlüssels. Escape-Schlüsselnamen waren niemals willkürliche Zeichenfolgen. Das ist eine ganz andere Sache.

Wir können die Beschränkung von system:/elektra .

Wir könnten eine Flagge in keyNew benötigen, um solche Namen zuzulassen. Andernfalls müsste eine Anwendung, die Schlüsselnamen vom Benutzer akzeptiert, die Eingabe bereinigen. Siehe auch das kdb import -Problem in # 3299.

Aber warum möchten Sie einschränken, welche Anwendungen in ihrem Teil ihrer Hierarchie gespeichert werden?

Ich möchte nicht einschränken, welche Anwendungen gespeichert werden, aber wie sie sie speichern. Dies gibt (Speicher-) Plugins mehr Freiheit.

Damit wird einer der Hauptvorteile von Elektra besiegt: "Der Administrator / Benutzer entscheidet über das Konfigurationsformat, nicht über den Anwendungsentwickler."

Es war nie möglich, dass ein Speicher-Plugin für eine Anwendung verwendet werden kann. Dies bedeutet nicht, dass wir dem Administrator / Benutzer die Befugnis entziehen, Mountpunkte zu ändern. Aber wir müssen ehrlich sein und einen großen Haftungsausschluss geben, dass dies mit einigen Risiken verbunden ist.

Das war nie mein Vorschlag. Natürlich sollten wir jeden gültigen JSON akzeptieren. Die Frage ist, welches KeySet wir produzieren. Wenn wir "@value" für Nicht-Blattwerte verwenden, wie oben vorgeschlagen, können wir trotzdem jeden gültigen JSON akzeptieren. Das resultierende KeySet hatte manchmal nur eine etwas andere Struktur.

Bei diesem Problem haben wir in etwa 10 Jahren bereits extrem viele Stunden verschwendet, ohne Fortschritte zu erzielen. Die erste Idee war Keytometa, dann Verzeichniswert mit vielen Schritten dazwischen. Warum nicht JSON so akzeptieren, wie es ist? Es funktioniert für die meisten Anwendungen. Lohnt sich eine etwas bessere Struktur wirklich?

Der Punkt ist, dass Anwendungen Wege finden, um Einschränkungen zu umgehen.

Anwendungen finden sogar Möglichkeiten, um das Fehlen einer Konfigurationsbibliothek zu umgehen. Warum sollten sie eine Konfigurationsbibliothek verwenden, die ihnen Einschränkungen gibt, die sie derzeit nicht haben? Es ist ziemlich trivial, eine Eigenschaftendatei zu implementieren, die beliebige Schlüsselnamen mit beliebigen Werten zulässt. Warum sollte Elektra von Nutzen sein, wenn es dies nicht einmal liefert?

Und in unserem Fall können wir ihnen sogar mit Bibliotheken helfen.

Zuerst müssen wir die Ziele klären, bevor wir komplexe Lösungen finden.

Ich stimme nicht zu. Speicher-Plugins sind bereits äußerst komplex,

Hast du dir simpleini, ni, c oder mini angesehen? Sie können immer noch problemlos ein nützliches Speicher-Plugin innerhalb von weniger als einem Tag schreiben.

Relativ gesehen wäre dies nur eine geringfügige Unannehmlichkeit. (vorausgesetzt, wir bieten eine gute Speicherbibliothek mit Hilfsfunktionen)

Leider gilt die Annahme nicht. Seit vielen Jahren haben wir auch versucht, Hilfsbibliotheken mit sehr geringem Erfolg zu erstellen. Was im Kern richtig gemacht wird, war immer die beste Lösung.

Sowohl CDATA- als auch HERE-Dokumente müssen eine gewisse Syntax behalten, aus der aktuellen Sicht von Elektra gibt es keinen Unterschied. Beide Versionen sind eine Einschränkung für Schlüsselnamen.

Nein, HERE-Dokumente behalten sich keine Syntax vor. Sie können im laufenden Betrieb (z. B. anhand der Daten) entscheiden, mit welchem ​​Schlüsselwort Sie das Ende des Dokuments markieren möchten.

Ich denke, wir sollten diese Funktionen lieber vergessen und Metadaten richtig verwenden, um Schlüsseln Semantik zu verleihen.
Sie haben gerade gesagt, dass einige Speicher-Plugins möglicherweise keine Metadaten unterstützen. Es scheint also, dass dies keine Option ist.

Der richtige Weg ist, Schlüssel im Namespace spec anzugeben. Die Speicher-Plugins in den anderen Namespaces müssen dann keine Metadaten speichern. Siehe Arbitrary_metadata.md-Entscheidung in # 3514

Wenn Sie nur Ihre Meinung ändern und sagen, dass ein Speicherformat die Fähigkeiten von Elektra einschränken kann, verschwindet das Problem natürlich. Dies ändert jedoch grundlegend das Versprechen von Elektra an die Benutzer. Wir würden alle Benutzer einschränken, nur um es einigen Entwicklern zu ermöglichen, einige Codezeilen zu speichern, die sich mit der Codierung spezieller Werte befassen.

Ich habe diese Frage in # 3515 getrennt

Ja, der Schlüsselname kann Einschränkungen unterliegen.
Bitte entscheiden Sie sich. Sie haben die ganze Zeit argumentiert, dass es keine Einschränkungen geben kann.

Schlüsselnamen, auch bekannt als keySetName können Einschränkungen haben (dh bei einigen Argumenten fehlschlagen), Schlüsselteilnamen, auch bekannt als keySetBaseName können keine Einschränkungen haben (bei keinem Argument fehlschlagen). Ich bin weder fanatisch noch dogmatisch, wir können dies und alles andere diskutieren, wenn Sie ein grundlegendes Problem mit unseren wichtigsten Zielen sehen.

Wir können die Einschränkung des Systems durchsetzen: / elektra.
Wir könnten ein Flag in keyNew benötigen, um solche Namen zuzulassen. Andernfalls müsste eine Anwendung, die Schlüsselnamen vom Benutzer akzeptiert, die Eingabe bereinigen.

Ich dachte an ein Plugin, das alles ablehnt, was in /elektra und nicht bestätigt, welche Tools dort schreiben dürfen. Ich denke jedoch, dass es eine niedrige Priorität hat.

Nein, HERE-Dokumente behalten sich keine Syntax vor. Sie können im laufenden Betrieb (z. B. anhand der Daten) entscheiden, mit welchem ​​Schlüsselwort Sie das Ende des Dokuments markieren möchten.

Ja, sie tun << ist weiterhin für das Starten von HIER-Dokumenten reserviert. Der Endmarker ist benutzerdefiniert, aber der Start kann offensichtlich nicht sein.
Das ist sowieso nicht wichtig.

Es war nie möglich, dass ein Speicher-Plugin für eine Anwendung verwendet werden kann.

Es ist in Ordnung für mich, wenn nicht alle Plugins alles unterstützen, aber wenn eine Anwendung ein benutzerdefiniertes Speicher-Plugin verwendet, hat der Administrator / Benutzer keine Wahl. Es sollte zumindest eine Auswahl geben, auch wenn es sich nur um YAML oder TOML handelt. Wenn nur ein auf Elektra zugeschnittenes benutzerdefiniertes Format alles unterstützt, dann befürchte ich, dass niemand Elektra verwenden wird. Für mich ist eines der wichtigsten Merkmale von Elektra, dass ein Amdin / Benutzer immer sein bevorzugtes Konfigurationsformat verwenden kann, unabhängig von der Anwendung.

Hast du dir simpleini, ni, c oder mini angesehen? Sie können immer noch problemlos ein nützliches Speicher-Plugin innerhalb von weniger als einem Tag schreiben.

c ist schreibgeschützt. mini unterstützt keine Metadaten und AFAICT löscht alle Kommentare aus einer Datei. simpleini auch keine Metadaten und listet viel mehr Einschränkungen in der README auf.

Im Allgemeinen sind INI-Plugins kein gutes Beispiel, da INI keine Spezifikation hat und daher keine Einschränkungen durch das Format auftreten.

ni basiert auf einer vorhandenen Bibliothek. Deshalb ist der Code ziemlich kurz und einfach.

Aber ni ist tatsächlich ein sehr gutes Beispiel dafür, was ich tun möchte. Es verwendet eine sehr spezifische Interpretation von INI-Dateien, die möglicherweise nicht von Anwendungsentwicklern gewünscht werden. Dies wirft tatsächlich eine andere Frage auf.

Was ist der wichtigere Anwendungsfall?

1. Konvertieren einer vorhandenen Anwendung in Elektra und Beibehalten der Konfigurationsdateien
2. Schreiben neuer Anwendungen, deren Konfigurationsformat auf dem für Elektra am besten geeigneten Format basiert

Für den ersten Fall benötigen wir Plugins, die jede Datei lesen und nützliche KeySet s erzeugen können.
Für den zweiten Fall ist selbst eine strenge Einschränkung, wie sie durch ni auferlegt wird, möglicherweise kein Problem.

Der richtige Weg ist, Schlüssel im Namespace spec anzugeben. Die Speicher-Plugins in den anderen Namespaces müssen dann keine Metadaten speichern.

Ja, das ist eine mögliche Lösung. Aber es erfordert viel Arbeit, damit spec richtig funktioniert. Zumindest benötigen wir einige Garantien für die Bestellung von Plugins innerhalb der Position postgetstorage .

Es verursacht jedoch einige Schwierigkeiten mit Metadaten, die aus dem Speicherformat abgeleitet werden (z. B. Typ, Array). Wäre es ein Fehler, wenn wir ein JSON-Array lesen würden, das keine übereinstimmenden array Metadaten in spec ?

Dies löst jedoch nicht das Problem für Nicht-Blatt-Schlüssel mit Werten.

Schlüsselnamen, auch bekannt als keySetName können Einschränkungen haben (dh bei einigen Argumenten fehlschlagen), Schlüsselteilnamen, auch bekannt als keySetBaseName können keine Einschränkungen haben (bei keinem Argument fehlschlagen).

Dies sind zwei völlig verschiedene Dinge. keySetName akzeptiert einen Schlüsselnamen entkam, während keySetBaseName nimmt einen Teil eines unescaped Schlüsselnamen. Natürlich hat ein maskierter Schlüsselname Einschränkungen.

Alles um Elektras Schlüsselnamen basiert jedoch auf einem _key name part_ (siehe auch das Dokument in # 3447). Die einzige Frage, die wir diskutieren müssen, ist:

_Was ist ein Schlüsselname? _

Es ist in Ordnung für mich, wenn nicht alle Plugins alles unterstützen, aber wenn eine Anwendung ein benutzerdefiniertes Speicher-Plugin verwendet, hat der Administrator / Benutzer keine Wahl.

Ich sehe nicht ein, wie das überhaupt möglich wäre. In Elektra können Sie immer Alternativen implementieren, solange diese Alternative geeignete KeySets für die Anwendung liefert. Das einzige, was behoben wird, ist das KeySet, aber wie das KeySet hergestellt wird, ist immer austauschbar. Für mich ist dies der Hauptvorteil von Elektra.

Aus diesem Grund sind die KeySets (einschließlich der Schlüsselnamen) die wichtigsten (und schwierigsten) Entscheidungen von allen.

Es sollte zumindest eine Auswahl geben, auch wenn es sich nur um YAML oder TOML handelt. Wenn nur ein auf Elektra zugeschnittenes benutzerdefiniertes Format alles unterstützt, dann befürchte ich, dass niemand Elektra verwenden wird. Für mich ist eines der wichtigsten Merkmale von Elektra, dass ein Amdin / Benutzer immer sein bevorzugtes Konfigurationsformat verwenden kann, unabhängig von der Anwendung.

Ich sehe nicht, wie sich eine der Entscheidungen, über die wir sprechen, auf die Möglichkeit auswirkt. Wenn Sie genug Aufwand in ein Speicher-Plugin für Ihr bevorzugtes Konfigurationsformat investieren (einschließlich syntaktischer Erweiterungen oder ähnliches), können Sie jede Anwendung zum Laufen bringen.

mini unterstützt keine Metadaten und AFAICT löscht alle Kommentare aus einer Datei. simpleini unterstützt auch keine Metadaten und listet viel mehr Einschränkungen in der README auf.

Für die meisten Anwendungen sind diese Einschränkungen irrelevant. Ein Tool, das ich benutze, funktioniert mit simpleini und auch mini als Backend.

Ich denke, wir sind bereits fast zu dem gleichen Schluss gekommen: Was auch immer passiert, um das richtige KeySet zu erhalten, muss innerhalb des Speicher-Plugins geschehen. Die Verwendung einer "Speicherbibliothek" ist natürlich vorteilhaft, aber am Ende ist es ein Implementierungsdetail. Die Idee, dass "spätere Plugins beheben, was das Speicher-Plugin falsch gemacht hat", schlug fehl. Warum brauchen wir also eine weitere Syntax im Schlüsselnamen? Welche Syntax auch immer benötigt wird, kann im Speicher-Plugin entfernt werden.

1. Konvertieren einer vorhandenen Anwendung in Elektra und Beibehalten der Konfigurationsdateien
2. Schreiben neuer Anwendungen, deren Konfigurationsformat auf dem für Elektra am besten geeigneten Format basiert

Imho "1." ist jetzt wichtiger, da wir dies für KDE brauchen. Wir brauchen Elektra also irgendwie in einer Form, um das Plugin kconfig nicht zu zerstören.

Etwa 2." Ich weiß nicht, was "am besten zu Elektra passt" bedeutet. Elektra hat keinen eigenen Zweck, sondern dient ausschließlich den Bedürfnissen von Entwicklern, Benutzern und Administratoren.

Es verursacht jedoch einige Schwierigkeiten mit Metadaten, die aus dem Speicherformat abgeleitet werden (z. B. Typ, Array). Wäre es ein Fehler, wenn wir ein JSON-Array lesen würden, dessen Spezifikation keine übereinstimmenden Array-Metadaten enthält?

Nein, nur der andere Weg ist ein Fehler: Wenn die Spezifikation ein Array erfordert, aber keines vorhanden ist.

Ja, das ist eine mögliche Lösung. Aber es erfordert viel Arbeit, damit die Spezifikation richtig funktioniert. Zumindest benötigen wir einige Garantien für die Bestellung von Plugins innerhalb der Postgetstorage-Position.

Ja, ich stimme vollkommen zu. Und mit spec sowieso etwas getan werden, wir können es nicht so lassen, wie es ist.

Dies löst jedoch nicht das Problem für Nicht-Blatt-Schlüssel mit Werten.

Sie haben argumentiert, dass dies sowieso nicht wichtig ist: stick_out_tongue_winking_eye:

Und ich stimme zu, für fast alle Anwendungen wird es nicht wichtig sein.

Was ist ein Schlüsselname?

Können Sie ein Problem machen, das die offenen / unklaren Punkte auflistet? Oder noch besser: Fügen Sie es zu # 3514 hinzu?

Es ist in Ordnung für mich, wenn nicht alle Plugins alles unterstützen, aber wenn eine Anwendung ein benutzerdefiniertes Speicher-Plugin verwendet, hat der Administrator / Benutzer keine Wahl.

Ich sehe nicht ein, wie das überhaupt möglich wäre. In Elektra können Sie immer Alternativen implementieren, solange diese Alternative geeignete KeySets für die Anwendung liefert. Das einzige, was behoben wird, ist das KeySet, aber wie das KeySet hergestellt wird, ist immer austauschbar. Für mich ist dies der Hauptvorteil von Elektra.

Aus diesem Grund sind die KeySets (einschließlich der Schlüsselnamen) die wichtigsten (und schwierigsten) Entscheidungen von allen.

Es sollte zumindest eine Auswahl geben, auch wenn es sich nur um YAML oder TOML handelt. Wenn nur ein auf Elektra zugeschnittenes benutzerdefiniertes Format alles unterstützt, dann befürchte ich, dass niemand Elektra verwenden wird. Für mich ist eines der wichtigsten Merkmale von Elektra, dass ein Amdin / Benutzer immer sein bevorzugtes Konfigurationsformat verwenden kann, unabhängig von der Anwendung.

Ich sehe nicht, wie sich eine der Entscheidungen, über die wir sprechen, auf die Möglichkeit auswirkt. Wenn Sie genug Aufwand in ein Speicher-Plugin für Ihr bevorzugtes Konfigurationsformat investieren (einschließlich syntaktischer Erweiterungen oder ähnliches), können Sie jede Anwendung zum Laufen bringen.

>

Ich hätte meiner Antwort mehr Kontext hinzufügen sollen. Ich denke, wir sind in dieser Hinsicht auf der Seite. Mein Kommentar war eine Antwort auf diese Aussage von Ihnen:

Ich denke, dass die meisten Anwendungen sowieso nicht sehr anspruchsvoll sein werden (z. B. nur Blattwerte haben und keine Metadaten außer Typ benötigen), daher ist alles, was wir hier diskutieren, nur für außergewöhnliche Anwendungen relevant. Für diese Anwendungen halte ich es für das Beste, dass Anwendungsentwickler ihre eigenen Speicher-Plugins entwickeln oder unsere besten Speicher-Plugins verwenden, die solche Dinge unterstützen.

Insbesondere der Teil: "Ich denke, es ist am besten, wenn Anwendungsentwickler ihre eigenen Speicher-Plugins entwickeln."

Dies wird zwar immer eine Option sein, aber ich denke, es sollte niemals etwas sein, das wir empfehlen oder sogar als Lösung vorschlagen. Die Verwendung eines benutzerdefinierten Speicher-Plugins entspricht nicht der Philosophie von Elektra und sollte so weit wie möglich vermieden werden. Hinweis: Mit "benutzerdefiniertem Speicher-Plugin" meine ich ein Plugin, das für die Verwendung mit einer bestimmten Anwendung entwickelt wurde, jedoch keine Garantie für die Kompatibilität mit dem Rest von Elektra übernimmt. Es wäre völlig in Ordnung, wenn jemand ein benutzerdefiniertes Format verwenden möchte und ein entsprechendes Plugin entwickelt, das mit der Standard-Elektra-Umgebung kompatibel ist.

Ich denke, wir sind bereits fast zu dem gleichen Schluss gekommen: Was auch immer passiert, um das richtige KeySet zu erhalten, muss innerhalb des Speicher-Plugins geschehen. Die Verwendung einer "Speicherbibliothek" ist natürlich vorteilhaft, aber am Ende ist es ein Implementierungsdetail. Die Idee, dass "spätere Plugins beheben, was das Speicher-Plugin falsch gemacht hat", schlug fehl.

Ja, das ist es im Grunde. Das Speicher-Plugin kann sich nicht auf andere Plugins verlassen (außer möglicherweise Binärwerte und dergleichen).

Obwohl vielleicht doch ein Plugin die Lösung ist. Ich muss weiter darüber nachdenken und werde die Idee veröffentlichen, wenn ich denke, dass es funktioniert.

Es verursacht jedoch einige Schwierigkeiten mit Metadaten, die aus dem Speicherformat abgeleitet werden (z. B. Typ, Array). Wäre es ein Fehler, wenn wir ein JSON-Array lesen würden, dessen Spezifikation keine übereinstimmenden Array-Metadaten enthält?

Nein, nur der andere Weg ist ein Fehler: Wenn die Spezifikation ein Array erfordert, aber keines vorhanden ist.

Gehen wir noch einen Schritt weiter. Was ist, wenn wir diesen JSON [ "a", "b" ] ohne Spezifikation haben und ihn in ein Format ohne Metadaten und ohne Arrays exportieren (z. B. mini )? Die Information, dass dies ein Array ist, würde verloren gehen.

Da dies ein Randfall ist, könnten wir einfach sagen: Das ist unglücklich, aber es ist, was es ist.

Und ich stimme zu, für fast alle Anwendungen wird es nicht wichtig sein.

Gleiches gilt für die Verwendung beliebiger Schlüsselnamen. Fast alle Anwendungen hätten kein Problem, wenn sie nicht /@elektra/ in ihren Schlüsselnamen verwenden könnten.

Können Sie ein Problem machen, das die offenen / unklaren Punkte auflistet? Oder noch besser: Fügen Sie es zu # 3514 hinzu?

Ich werde irgendwo eine Liste erstellen, damit wir sie am Montag besprechen können.

Es wäre völlig in Ordnung, wenn jemand ein benutzerdefiniertes Format verwenden möchte und ein entsprechendes Plugin entwickelt, das mit der Standard-Elektra-Umgebung kompatibel ist.

Ich habe tatsächlich in diese Richtung gedacht. Aber ja, Besonderheiten schleichen sich leicht ein. Beispielsweise kann das kconfig -Plugin der Metadaten nur ein einziges Zeichen lang sein, so dass es offensichtlich nicht sehr kompatibel mit unseren Metadaten ist (zumindest solange der Parser dieses Zeichen nicht neu zuordnet auf die eigentliche Bedeutung, die im Moment nicht vorkommt). Im Moment leiten wir einfach die Metadaten mit einem Zeichen durch unsere Ebene und tun bei Bedarf in der Bibliothek kconfig was passiert wäre, wenn die Datei direkt analysiert worden wäre.

@mpranj hast du schon [$e] scheint ziemlich oft zu existieren.

Obwohl vielleicht doch ein Plugin die Lösung ist. Ich muss weiter darüber nachdenken und werde die Idee veröffentlichen, wenn ich denke, dass es funktioniert.

Im Moment würde ich es vorziehen, wenn wir die Dinge reparieren, bei denen wir bereits wissen, wie man sie repariert.

Da dies ein Randfall ist, könnten wir einfach sagen: Das ist unglücklich, aber es ist, was es ist.

Wenn Sie "Feature X" möchten, können Sie ohne diese Funktion kein Plugin in der Import / Export-Kette haben. Das gleiche gilt für Kommentare und so weiter.

Nicht-Blatt-Schlüssel mit Werten.
Gleiches gilt für die Verwendung beliebiger Schlüsselnamen. Fast alle Anwendungen hätten kein Problem, wenn sie / @ elektra / nicht in ihren Schlüsselnamen verwenden könnten.

Ja. Es gibt aber auch einen großen Unterschied zwischen etwas, das mit einigen Plugins nicht funktioniert, und etwas, das mit Elektra überhaupt nicht funktioniert.

Ich werde irgendwo eine Liste erstellen, damit wir sie am Montag besprechen können.

: +1:

Es gibt aber auch einen großen Unterschied zwischen etwas, das mit einigen Plugins nicht funktioniert, und etwas, das mit Elektra überhaupt nicht funktioniert.

Ich verstehe, aber realistisch gesehen, wie oft wird es tatsächlich ein Problem sein, keine /@elektra/ Schlüssel zu haben?

Obwohl vielleicht doch ein Plugin die Lösung ist. Ich muss weiter darüber nachdenken und werde die Idee veröffentlichen, wenn ich denke, dass es funktioniert.

Im Moment würde ich es vorziehen, wenn wir die Dinge reparieren, bei denen wir bereits wissen, wie man sie repariert.

Die Idee war ein Plugin, das immer gemountet ist und einige Schlüsselnamen codiert / decodiert. Dann muss ein Speicher-Plugin nur mit KeySet umgehen, die zB keine /@elektra/ Schlüssel enthalten. Aufgrund der Codierung kann die Anwendung jedoch weiterhin einen beliebigen Schlüsselnamen verwenden. Das Speicher-Plugin kann dann /@elektra/ Schlüssel für seinen eigenen Zweck verwenden, z. B. Metadaten und Nicht-Blatt-Werte.

Der Effekt wäre eine kleine Einschränkung für Speicherdateien, aber keine Einschränkung für Anwendungen. Die Komplexität der Speicher-Plugins bleibt ebenfalls unberührt, da das Speicher-Plugin keine /@elektra/ -Schlüssel verwenden muss. Nur diejenigen Plugins, die zB Metadaten unterstützen möchten, müssen zusätzlichen Code schreiben, aber das ist immer der Fall.

Ich verstehe Ihren Standpunkt, aber realistisch gesehen, wie oft wird es tatsächlich ein Problem sein, / @ elektra / keys nicht zu haben?

Wahrscheinlich überhaupt kein Problem. Aber es wird jetzt genauso ein Problem sein wie später. Warum also jetzt reservieren und nicht, wenn wir wirklich einen Anwendungsfall finden, in dem so etwas benötigt wird? Dann wissen wir, dass es nicht nur eine Fantasie ist und können einen geeigneten Namen wählen.

In Programmiersprachen reservieren wir (normalerweise) Schlüsselwörter nur, wenn wir tatsächlich syntaktische Erweiterungen vornehmen.

zB Metadaten

Für Metadaten zu Schlüsseln ist spec die bessere Lösung, da sie sich auf alle Namespaces bezieht. Nicht spezifizierte Metadaten sind grundsätzlich nur nützlich, um die Formatierung beizubehalten und ähnliches.

weil das Speicher-Plugin keine / @ elektra / -Schlüssel verwenden muss

Es ist nicht so, dass ein Speicher-Plugin einen Namen verwendet, die Frage ist das Verhalten, wenn es in einer Datei auf <strong i="14">@elektra</strong> = something stößt.

Warum also jetzt reservieren und nicht, wenn wir wirklich einen Anwendungsfall finden, in dem so etwas benötigt wird?

Weil dies eine große Veränderung ist und vor 1.0 der richtige Moment ist, um solche Dinge zu tun. Zumal sich bereits Schlüsselnamen ändern.

Es gibt momentan auch einen sehr realen Anwendungsfall dafür. Zumindest können damit Nicht-Blatt-Schlüssel mit Werten in einem beliebigen Format gespeichert werden.

Für Metadaten zu Schlüsseln ist spec die bessere Lösung, da sie sich auf alle Namespaces bezieht.

Ich werde nur array erwähnen. Denken Sie ein wenig über das Zeug in # 3514 nach und sagen Sie mir dann, wie man ein Array richtig in einer Java-Eigenschaftendatei speichert.

Es wäre schön, wenn Metadaten nur in spec:/ gespeichert wären (das würde auch ein Problem mit dem spec Plugin lösen), aber einige sehr große Änderungen an Elektra erfordern würden, damit es gut funktioniert.

Die Frage ist das Verhalten, wenn es in einer Datei auf <strong i="17">@elektra</strong> = something stößt

Wenn das Plugin @elektra , um etwas zu codieren (z. B. Nicht-Blatt-Werte), geschieht dies.
Andernfalls: "FEHLER: unzulässiger Schlüsselname"

Ich werde irgendwo eine Liste erstellen, damit wir sie am Montag besprechen können.

Wie in https://github.com/ElektraInitiative/libelektra/issues/3223#issuecomment -709389141 versprochen, habe ich jetzt # 3517 hinzugefügt.

Sagen Sie mir, wie ein Array ordnungsgemäß in einer Java-Eigenschaftendatei gespeichert wird.

Es funktioniert nur mit spec .

Aber es würde einige sehr große Änderungen an Elektra erfordern, damit es gut funktioniert.

Sind einige Änderungen erforderlich, die noch nicht im Issue-Tracker enthalten sind? Ich denke, es ist ein Muss für 1.0, dass zumindest die Grundlagen der Spezifikation gut funktionieren (und um das nicht funktionierende Zeug loszuwerden).

Es funktioniert nur mit spec .

Aber wie? Sie benötigen die array -Metadaten in den anderen Namespaces, um zu wissen, wie groß das Array tatsächlich ist.

Sind einige Änderungen erforderlich, die noch nicht im Issue-Tracker enthalten sind? Ich denke, es ist ein Muss für 1.0, dass zumindest die Grundlagen der Spezifikation gut funktionieren (und um das nicht funktionierende Zeug loszuwerden).

Es ist unmöglich zu sagen. Wir müssen entscheiden, was die Spezifikation tatsächlich tun soll. Dann müssen wir herausfinden, ob und wie das möglich ist. Selbst dann ist es sehr wahrscheinlich, dass wir einige Randfälle finden, die nicht funktionieren. Elektra ist einfach so kompliziert, dass es fast unmöglich ist, darüber nachzudenken, und eine gute Testabdeckung ist mindestens genauso schwierig. Ein Großteil von Elektra basiert auch immer noch auf lose oder gar nicht definierten Prinzipien.

Das größte Problem sind definitiv die aktuellen Plugin-Positionen. Die Behebung dieser Probleme erfordert jedoch viel Arbeit. IMO dieser Teil benötigt im Wesentlichen eine komplette Neugestaltung.

Aber wie? Sie benötigen die Array-Metadaten in den anderen Namespaces, um zu wissen, wie groß das Array tatsächlich ist.

Ja, spec müsste die Semantik der Metadaten wie Arrays wirklich verstehen. Es würde also alle Namespaces überprüfen, wie das Array tatsächlich aussieht, und dann die richtigen Metadaten array hinzufügen.

Elektra ist einfach so kompliziert, dass es fast unmöglich ist, darüber nachzudenken, und eine gute Testabdeckung ist mindestens genauso schwierig.

Ich stimme zu, also lass es einfacher machen. Jetzt ist die perfekte Gelegenheit. Wir haben viel darüber gelernt, was nicht geht. Also lasst uns das Zeug loswerden.

Das größte Problem sind definitiv die aktuellen Plugin-Positionen. Die Behebung dieser Probleme erfordert jedoch viel Arbeit. IMO dieser Teil benötigt im Wesentlichen eine komplette Neugestaltung.

Ich stimme @mpranj immer mehr zu, dass Hooks für bestimmte globale Plugins keine so schlechte Idee sind. Die Anforderungen für solche Plugins sind ziemlich kompliziert und daher würde die generische Positionierung zu kompliziert werden.

Wir hätten also einfach keine generischen globalen Plugin-Positionen, sondern nur solche, die für mmap, spec und Benachrichtigung spezifisch sind (die einzige, die wir wirklich für 1.0 benötigen). Generische Positionen wären nett, aber es liegt eindeutig außerhalb unserer Fähigkeit, dies zu testen. Ich habe die Entscheidung in 89b29034e1d505f36d298f01bf0fcfd13aa1af70 geändert

Weitere Diskussionen bitte in # 3514