Libelektra: Caracteres reservados en nombres clave

Vea también # 2698 para una discusión sobre qué carácter se usará para la matriz (globbing)

En primer lugar, si enumera \ , también debe poner / en la lista. La barra es claramente el carácter reservado prototípico (carácter con un significado especial) en Elektra.

En segundo lugar, "usado para globbing" y "usado para referirse a parentKey, por ejemplo, en complementos condicionales" no son casos de uso válidos aquí. Estos no son significados especiales durante la anulación de escape. Si desea evitar una interpretación especial que suceda más tarde (por ejemplo, mediante un complemento o biblioteca), debe saber que esta interpretación se basa en el nombre de clave de escape (lo que sería malo, como se describe en https: // github. com / ElektraInitiative / libelektra / issues / 2698 # issuecomment-554636250), o debe asegurarse de que el nombre sin escape no se pueda interpretar de forma especial.

Tomemos # como ejemplo. Nuestra biblioteca globbing interpreta el nombre de clave /a/# en el sentido de "coincidir con cualquier elemento de la matriz /a ". Si no queremos eso, pero queremos hacer coincidir /a/# literalmente, necesitamos usar algún tipo de escape. Sin embargo, /a/\# no puede funcionar. ¿Qué logra la barra invertida durante la eliminación del escape del nombre de la clave? Para evitar la interpretación especial de la biblioteca globular, tendría que permanecer allí durante la eliminación. Pero eso viola la regla (°) de que una barra invertida debe escaparse, si no es un carácter de escape en sí mismo (no es un carácter de escape, si no desaparece durante la eliminación de escape). Por lo tanto, necesitamos usar /a/\\# , que se eliminará en ⊙a⊙\# (⊙ en lugar de NUL, se omite el espacio de nombres y el terminador). Pero, en ese caso, # no tiene un significado especial para la eliminación del nombre de clave y no tiene que ser considerado en absoluto.

En otras palabras, para dar una razón por la que un personaje tiene que escapar (por qué está reservado), debes pensar en _ "¿Qué comportamiento de elektraKeyNameCanonicalize o elektraKeyNameUnescape evitaría el escape?" _ .

Para los personajes que realmente queremos hacer "reservados", hay una decisión que tenemos que tomar aquí. ¿Son estos _caracteres con un significado especial_ o _caracteres reservados_ reales?

En mi opinión, _caracteres con significado especial_ son caracteres normales que se pueden usar como tales, pero pueden tener una interpretación especial en un contexto determinado (por ejemplo, % si es la parte clave completa).

_Los caracteres reservados_, por otro lado, están reservados para contextos especiales. No se pueden usar normalmente y solo se permiten en contextos especiales, en los que tienen un significado especial.

Un _carácter con significado especial_ sólo tiene que escaparse en el contexto, en el que tiene su interpretación especial, si no se desea esta interpretación especial. Fuera de este contexto, el escape puede estar permitido o no, dependiendo de nuestra postura sobre el escape innecesario (°°).

Por otro lado, un _ carácter reservado_ debe escaparse siempre que no tenga un significado especial. Esto significa que, en el contexto donde tiene un significado especial, se puede escapar, para evitar el significado especial. Fuera de este contexto, debe escaparse.

Como ejemplo, veamos % . Si una parte clave completa es solo % (por ejemplo, /%/ ), esta parte no se convierte en una parte vacía. En ambos casos, la barra invertida en /\%/ evitará la interpretación especial y no se escapará a una parte que sea % . La diferencia se vuelve notable, sin embargo, si se analizan diferentes contextos, como /a%b/ .

Si tratamos a % como un _ carácter reservado_, entonces /a%b/ es un nombre / parte de clave ilegal y deberíamos arrojar un error. La forma correcta de lograr la parte sin escape a%b con un _ carácter reservado_ sería usando /a\%b/ .

Si vemos % como un _ personaje con un significado especial_, entonces /a%b/ sería correcto y no escaparía a a%b . Nuevamente, si también se permite /a\%b/ , depende de nuestra postura sobre el escape innecesario. Si está permitido, también elimina el escape en a%b .

Nota: Para / no hay decisión, ambas interpretaciones son equivalentes, ya que no hay contexto, en el que / no tiene un significado especial. Para \ ya decidimos (en # 3115) tratarlo como un _ carácter reservado_ y, por lo tanto, requerir un escape, cuando no se usa como un carácter de escape en sí.

La decisión anterior, por supuesto, también requiere que definamos, en qué contextos pueden estos personajes, ahora o en el futuro , tener significados especiales.

Aquí hay dos soluciones fáciles:
Trate todo (excepto / y \ ) como _caracteres con significado especial_, permita escapes innecesarios y para los no utilizados defina que tienen una interpretación especial en todos los contextos. La interpretación especial para estos sería que hacen ilegal un nombre clave. Por lo tanto, los que no se utilizan siempre deben escaparse. Cualquier otro de la lista de personajes siempre se puede escapar, pero sólo debe ser, si queremos evitar una interpretación especial específico.

---

(°) Como se indica en el # 3115, esta regla hace que todo el sistema sea mucho más fácil de entender. En un nombre de clave de escape (válido), una barra invertida siempre escapa de algo. En un nombre de clave sin escape (válido), una barra invertida siempre es literalmente una barra invertida.

(°°) Si adoptamos una postura muy estricta sobre el escape innecesario, debería ser posible obtener una relación 1: 1 entre los nombres de claves con escape y sin escape. Por supuesto, esto requiere más esfuerzo en la validación de nombres clave y, por lo tanto, tendrá un impacto en el rendimiento (debe probarse si este impacto es significativo de alguna manera).

En primer lugar, si enumera \, también debe poner / en la lista. La barra es claramente el carácter reservado prototípico (carácter con un significado especial) en Elektra.

Gracias, lo agregué. Si encuentra más personajes, simplemente puede agregarlos a la publicación superior.

En segundo lugar, "usado para globbing" y "usado para referirse a parentKey, por ejemplo, en complementos condicionales" no son casos de uso válidos aquí. Estos no son significados especiales durante la anulación de escape.

Sí, por supuesto, también podemos usar otro carácter de escape o dos \ para algunos de estos caracteres. ¿Pero esto será más complicado para los usuarios?

¿Qué logra la barra invertida durante la eliminación del escape del nombre de la clave?

Tenía en mente que keyAddBaseName (key, "_") realmente agregará \_ . Entonces, para obtener un _ (con el significado del carácter globular), necesitaría usar keyAddName.

Por ejemplo, @sanssecours actualmente usa _ dentro de los nombres de clave para el complemento de valor de directorio. Por supuesto, no hay forma de escapar de esto, ya que escribir estos motores de escape no es trivial. Tenía la esperanza de que pudiéramos tener un solo lugar para implementar tal escape.

Para los personajes que realmente queremos hacer "reservados", hay una decisión que tenemos que tomar aquí. ¿Estos caracteres tienen un significado especial o son caracteres reservados reales?

Si no tienen un significado especial ahora, se reservan para que podamos darles un significado especial más adelante. No podemos "reservar" o "dar un significado especial" en un momento posterior, ya que las aplicaciones ya podrían usar dichos caracteres.

Para que quede claro: en la publicación superior, el "significado especial" y "reservado" son sinónimos del motor de escape. Y los mantendría como sinónimos para facilitar el escape.

Los caracteres reservados, por otro lado, están reservados para contextos especiales. No se pueden usar normalmente y solo se permiten en contextos especiales, en los que tienen un significado especial.

Para hacer que todo este motor de escape sea sensato, simplemente asumiría que los caracteres especiales son siempre especiales, excepto cuando se escapan.

En particular, me gustaría evitar situaciones en las que los caracteres adquieran un significado especial si se agrega un carácter de escape. Este es un truco feo y hace, por ejemplo, regex innecesariamente complicado.

Si vemos% como un carácter con un significado especial, entonces / a% b / sería correcto y dejaría de escapar en% b.
De nuevo, si también se permite / a% b /, depende de nuestra postura sobre el escape innecesario. Si está permitido, también elimina el escape en% b.

Exactamente. El motor no puede evitar completamente la creación de nombres con significados incorrectos. Por eso creo que no deberíamos intentar hacerlo. Por ejemplo, el% en los marcadores de posición debe tener un número par de apariciones, pero hay excepciones. Y tal vez alguna extensión de los valores contextuales agregue más excepciones.

Si adoptamos una postura muy estricta sobre el escape innecesario, debería ser posible obtener una relación 1: 1 entre los nombres de clave con escape y sin escape. Por supuesto, esto requiere más esfuerzo en la validación de nombres clave y, por lo tanto, tendrá un impacto en el rendimiento (debe probarse si este impacto es significativo de alguna manera).

Creo que nuestro objetivo más importante debería ser que el escape sea fácil de entender y usar. El escape anterior se esforzó en que todos los nombres fueran válidos. Estos objetivos en su mayoría causan dolor de cabeza, pero en realidad no mejoran la usabilidad. Si alguien coloca \ en lugares arbitrarios, está bien rechazar algunos nombres. Pero delante de los caracteres especiales, \ debería ser siempre válido y quitar cualquier significado especial (futuro).

Tenía en mente que keyAddBaseName (key, "_") realmente agregará \_ . Entonces, para obtener un _ (con el significado del carácter globular), necesitaría usar keyAddName.

Esto es muy confuso para mí ...

La semántica de keyAddBaseName (Key * key, const char * x) es:
x es una parte sin escape . Se agregará directamente al final de key->ukey . Su forma de escape se agregará al final de key->key .

La semántica de keyAddName (Key * key, const char * x) es:
x es un sufijo de nombre de escape (es decir, cero o más partes, sin espacio de nombres). Se canonicalizará y se agregará al final de key->key . El formulario sin escape se agregará al final de key->ukey .

Ahora, desea que keyAddBaseName (key, "_") agregue la parte \_ al nombre de escape y la parte _ al nombre sin escape. Y eso no debería tener ningún impacto en el globbing. Pero keyAddName (key, "_") debería tener significado para globbing, entonces, ¿qué hace? _ no se puede eliminar de ninguna manera, es solo un carácter. Así que tenemos que agregar _ tanto al nombre con escape como al sin escape. Pero ambas versiones producen el mismo nombre sin escape, lo que significa que debería tener el mismo significado para globbing ...

actualmente utiliza _ dentro de los nombres de las claves para el complemento de valor de directorio.

AFAIK directoryvalue solo usa la parte clave /__directoryvalue/ . Esto de ninguna manera choca con el uso de globbing de /_/ .

No podemos "reservar" o "dar un significado especial" en un momento posterior, ya que las aplicaciones ya podrían usar dichos caracteres.

Sería un gran cambio radical, como el que estamos haciendo con los nombres clave ahora.

Creo que debemos distinguir dos cosas:

1. Caracteres que tienen un significado especial para keySetName (o más específicamente elektraKeyNameCanonicalize y elektraKeyNameUnescape ).
2. Caracteres que tienen un significado especial para un complemento, biblioteca u otra parte de Elektra que no está relacionada con la manipulación del nombre de la clave.

El primer grupo será alguna forma de carácter reservado, cuyo uso inadecuado resultará en un keySetName fallido (y keyNew devolverá NULL ). Aquí es donde ayuda escapar con una barra invertida, ya que la barra invertida le dice a keySetName que tome el siguiente carácter literalmente e ignore cualquier significado que pueda tener.

El segundo grupo es completamente diferente. No hay nada que podamos hacer durante keySetName (o keyAddName , keyAddBaseName , etc.) para cambiar si un carácter de este grupo tiene un significado especial para algún complemento o no. Depende totalmente del complemento decidir eso y cualquier forma de escape del complemento que pueda permitir evitar que el significado especial llegue al complemento. Tenga en cuenta que dijimos que keySetName falla y keyNew devuelve NULL para nombres no válidos. En keySetName
Por ejemplo, no podemos decir que /# tiene un significado especial, /#a no está permitido, pero /\# no tiene un significado especial y /\#a está permitido. No tenemos idea de cómo se utilizará esto. Si no permitimos algunas claves, ningún complemento puede usarlas. (Nota: en el párrafo anterior: complemento = complemento, biblioteca, aplicación, etc.)

Si realmente desea unificar cuando algo puede tener un significado especial para un complemento / biblioteca, solo puedo ver que algo como esto funcione:

Defina algunas reglas de escape para % , . , / y \ , ya que el efecto keySetName . Haga las cosas del índice de matriz de # 2698. Las partes del nombre de clave (con escape y sin escape) que comienzan con @ deben tener el formato (expresión regular) @[^@]+@.+ . El carácter @ no puede aparecer en ningún otro contexto. Todo lo demás no tiene un significado especial durante keySetName y se puede usar sin restricciones. Los complementos, bibliotecas, etc. NO PUEDEN atribuir un significado especial a ningún carácter individual oa una parte del nombre de la clave, excepto a las partes del nombre de la clave sin escape que comienzan con @ . Una parte del nombre de clave sin escape del formulario (regex) @[^@]+@.+ solo puede tener un significado especial para el complemento nombrado por la parte [^@] de la expresión regular. Cuál es ese significado, depende del complemento y está determinado por la parte posterior al segundo @ .

Reconozco que esto es totalmente diferente del enfoque actual y completamente irrazonable de implementar, si queremos lanzar 1.0 pronto, pero es el único enfoque de trabajo que puedo ver, que nos permite decir definitivamente si una parte clave tiene alguna significado especial o no.

Creo que debemos distinguir dos cosas:

Mi esperanza era que pudiéramos descartar esta distinción para que todo el escape fuera más fácil de entender. Entonces keyAddBaseName nunca agrega algo que tenga un significado para Elektra.

Si esto no es posible, el requisito mínimo es que sea posible pasar cualquier cadena a keyAddBaseName y obtener la misma cadena cuando solicite el nombre base con keyBaseName , consulte # 2698.

Sí, rompería algunas ocurrencias de keyAddBaseName donde se agregaron los nombres de las matrices. Pero de todos modos romperá algunos casos, ya que ahora no todos los nombres de las matrices son válidos, por lo que también necesitamos romper algún código:

1. el código que asumió que cada cadena se puede configurar o
2. se puede agregar el código que asumió matrices.

Es muy claro para mí que no hay que romper 1., el código es decir, que asume cada cuerda se puede pasar a keyAddBaseName . "2." no es tan importante, estas son algunas ocurrencias que se pueden arreglar.

Otro ejemplo al lado de SSID: las entradas de fstab pueden tener básicamente todo, incluido /. O los nombres de los puntos de montaje dentro de Elektra.

Entonces keyAddBaseName nunca agrega algo que tenga un significado para Elektra.

Veo ahora que esto vuelve a ser el principal problema en el corazón de Elektra. Todo debe ser un sistema coherente y bien definido, pero al mismo tiempo todo debe ser flexible y los complementos deben usarse tanto como sea posible. Esto simplemente no puede funcionar.

El problema específicamente es la frase "significado para Elektra". Podemos asegurarnos de que keyAddBaseName nunca agregue algo que tenga significado para elektra-core , o en términos más claros, que keyAddBaseName agregue su argumento como una nueva parte de nombre de clave sin escape. Pero para una aplicación, "Elektra" también significa cualquier complemento de Elektra. En esa interpretación se vuelve muy difícil evitar que keyAddBaseName agregue algo "con significado". Cualquier complemento podría decidir atribuir significado a cualquier nombre de clave sin escape en cualquier momento. Como dije, la única solución es introducir un sistema muy restrictivo, como el que se propuso anteriormente con @ . Si se te ocurre algo diferente, avísame, pero por todo lo que se me ocurrió hasta que lo sepa, encontré un problema.

Para mí es muy claro que no debemos romper 1., es decir, código que asumía que cada cadena se puede pasar a keyAddBaseName

¿Por qué? Para mí está casi claro, ¿por qué es preferible esto? Los nombres de archivo UNIX, por ejemplo, no pueden contener / y nadie pensó que eso fuera un problema. (No permitir / hace que dividir rutas de UNIX en partes sea mucho más simple que con nombres de clave).

Ya estamos rompiendo (casi) CADA pieza de código que interactúa con Elektra agregando : después del espacio de nombres. En el estado actual de las cosas, solo las claves en cascada sin partes de la matriz y también excluyendo algunas otras cosas de caracteres especiales continuarán funcionando sin necesidad de cambios. La compatibilidad con versiones anteriores está fuera de la ventana.

"2." no es tan importante, estas son algunas ocurrencias que se pueden arreglar.

No estaría tan seguro de eso. De hecho, solo conozco una parte de Elektra que realmente asume que keyAddBaseName escapa de todo y eso es elektra-kdb y las herramientas que crean puntos de montaje.

Las entradas de fstab pueden tener básicamente todo, incluido /

¿No estás seguro de por qué es relevante?

O los nombres de los puntos de montaje dentro de Elektra.

Para crear el punto de montaje user:/my/mount las herramientas colocan la configuración del punto de montaje en system:/elektra/mountpoints/user:\/my\/mount , pero también podrían usar cualquier otra clave única directamente debajo de system:/elektra/mountpoints , porque el punto de montaje real es el valor de, por ejemplo, system:/elektra/mountpoints/user:\/my\/mount/mountpoint . AFAICT system:/elektra/mountpoints podría ser una matriz. No he encontrado ningún lugar que llame a keyBaseName en una tecla directamente debajo de system:/elektra/mountpoints .

Puede haber algún lugar que use mountGetMountpoint o mountGetBackend para obtener el punto de montaje y reconstruir system:/elektra/mountpoints/user:\/my\/mount/ para acceder a algunas de las configuraciones, pero eso podría resolverse fácilmente agregando el system:/elektra/mountpoints clave debajo de la cual la configuración se almacena como un campo en struct _Backend .

En breve:

el requisito mínimo es que sea posible pasar cualquier cadena a keyAddBaseName y obtener la misma cadena cuando se solicita el nombre base con keyBaseName

Esto es facil. Pero combinarlo con " keyAddBaseName aceptará todas las cadenas" es muy difícil o casi imposible.

Veo ahora que esto vuelve a ser el principal problema en el corazón de Elektra. Todo debe ser un sistema coherente y bien definido, pero al mismo tiempo todo debe ser flexible y los complementos deben usarse tanto como sea posible. Esto simplemente no puede funcionar.

Sí, pero no lo llamaría un problema sino un desafío. Queremos la mejor Elektra posible y, por supuesto, a veces se producen objetivos contradictorios.

Como dije, la única solución es introducir un sistema muy restrictivo, como el de @ propuesto arriba.

Sí, también veo que no será posible tenerlo todo. Con el escape de matriz ya estamos bastante limitados a un escape de prefijo, es decir, no podemos escapar de otros caracteres dentro de los nombres base.

Pero este prefijo de escape podría ser suficiente. Y esto debería ser extensible a todos los personajes propuestos anteriormente. La limitación sería que la parte completa del nombre de la clave se escapa o nada en absoluto.

Por supuesto, el escape no sería mágico, pero las aplicaciones necesitarían verificar si el significado de keyBaseName se ha eliminado o si proporcionamos un keyUnescapedBaseName diferente para que los usuarios de la API puedan tener la cadena con o sin prefijo de escape.

¿Por qué? Para mí está casi claro, ¿por qué es preferible esto? Los nombres de archivo UNIX, por ejemplo, no pueden contener / y nadie pensó que eso fuera un problema. (No permitir / hace que dividir rutas de UNIX en partes sea mucho más simple que con nombres de clave).

Es un problema para todos los que implementan un explorador de archivos. Algunas aplicaciones tenían técnicas de codificación de URL para obtener / en los nombres de los archivos. La "solución" más moderna es utilizar el carácter Unicode 'DIVISION SLASH' (U + 2215) para las barras.

Además, tenga en cuenta que la única razón de la existencia de Elektra es que la semántica del sistema de archivos UNIX no es adecuada para la configuración. En la configuración, las secuencias arbitrarias para los nombres de las partes clave, incluido /, se utilizan comúnmente y, por lo tanto, deben ser compatibles. Por ejemplo, en YAML / se permiten caracteres en las partes del nombre de clave y también en TOML hay "claves entre comillas".

Ya estamos rompiendo (casi) CADA fragmento de código que interactúa con Elektra agregando: después del espacio de nombres. En el estado actual de las cosas, solo las claves en cascada sin partes de la matriz y también excluyendo algunas otras cosas de caracteres especiales continuarán funcionando sin necesidad de cambios. La compatibilidad con versiones anteriores está fuera de la ventana.

Sí, y estoy muy agradecido de que estés haciendo esto. No hubiera podido hacer esto solo.

No estaría tan seguro de eso. De hecho, solo conozco una parte de Elektra que realmente asume que keyAddBaseName se escapa de todo y es elektra-kdb y las herramientas que crean puntos de montaje.

Otra parte son los SSID. Este no fue un ejemplo sintético, pero Broadcom lo ha implementado para sus dispositivos bluetooth. Así que confían en que pueden agregar cualquier nombre base.

Esto es facil. Pero combinarlo con "keyAddBaseName debe aceptar todas las cadenas" es muy difícil o casi imposible.

Sí, muy difícil, pero también una característica única muy agradable que ni siquiera UNIX tenía antes. Podemos estar orgullosos de eso.

Por ejemplo, en YAML / se permiten caracteres en las partes del nombre de clave y también en TOML hay "claves entre comillas".

Esto es realmente lo que pensé que podríamos presentar, ver más abajo.

Creo que todo esto se puede resolver introduciendo algo similar a "claves entre comillas". Voy a llamarlos _partes clave literal_.

Si una parte clave comienza con @ (podría ser otro carácter, por supuesto), la siguiente parte clave es una _parte clave literal_. Una _parte de clave literal_ puede contener CUALQUIER secuencia de bytes, incluidos cero bytes.

Su forma sin escape es la siguiente:

• Una _parte de clave literal_ comienza con un carácter @ .
• Otros caracteres @ se codifican como @@ .
• Los bytes cero se codifican como @0 .
• @ no puede ocurrir de otra manera.
• Como siempre, un byte cero termina la parte clave.

La forma de escape es un poco diferente, para permitir una impresión más fácil:

• Una _parte de clave literal_ comienza con un carácter @ .
• La _parte de clave literal_ NO termina con un / . Solo otro @ seguido de un / o un byte cero (final de la cadena), termina la parte de clave _literal.
• Cualquier byte puede codificarse como @XX@ , donde XX es la forma hexadecimal del byte. Por lo tanto, los caracteres @ deben codificarse como @40@ .

Ahora keySetBaseName y keyAddBaseName aceptan CUALQUIER parte de clave válida sin escape como argumentos. Establecen / agregan su argumento sin modificar como la última parte del nombre de clave sin escape. Por lo tanto, keyBaseName devolverá el mismo argumento. Además keySetBaseName y keyAddBaseName convierten la parte sin escape en su forma de escape y la configuran / agregan como la última parte del nombre de escape.

Para solucionar el problema de "queremos añadir algo como parte clave", introducimos:

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

Estas funciones aceptan CUALQUIER secuencia de bytes como argumento bytes . Luego, convierten el argumento en una _parte de clave literal_ sin mayúscula_ prefijándolo con @ , reemplazando otros @ con @@ y cero bytes con @0 . Esto luego se pasa a keySetBaseName o keyAddBaseName .

Para facilitar la decodificación de _literal key part_, también podríamos agregar funciones de decodificación a la API pública.

Me gusta mucho más, porque deja muy claro cuándo el usuario tiene la intención de agregar cosas arbitrarias al nombre de la clave y cuándo este no es el caso.

keySet / AddLiteralBaseName es una propuesta para agregar una nueva característica. Actualmente no tenemos una forma de codificar bytes nulos en nombres de clave. Cuando alguien lo necesite, podemos volver a su propuesta.

Por ahora, sin embargo, necesitamos una buena semántica para keyAdd / SetBaseName. Como se describe muy largo, idealmente debería ser cualquier cadena, ya que de lo contrario muchos complementos y aplicaciones tendrán errores porque no esperan que algunas cadenas no funcionen. #_10 es una parte de nombre de clave válida, se puede usar como parte de nombre de clave en básicamente todos los complementos o aplicaciones de almacenamiento, no podemos discutir sobre eso. Definitivamente no es una buena idea dejar que un complemento de almacenamiento falle porque encontró #_10 algún lugar como parte del nombre clave durante el análisis. Y tampoco es una buena idea exigirles que utilicen una API diferente con un argumento de tamaño si de todos modos no tienen bytes nulos. En realidad, el hecho de que casos como #_10 o / no necesiten un manejo especial es la razón de la existencia de keyAdd / SetBaseName.

Por cierto. tal vez sea mejor si nos vemos, por ejemplo, el martes?

Actualmente no tenemos una forma de codificar bytes nulos en nombres de clave. Cuando alguien lo necesite, podemos volver a su propuesta.

Este es el punto menos importante de la propuesta. Solo permite cero bytes, porque no veo una razón por la que no lo haría.

De todos modos, ya hay un caso de uso:

Otra parte son los SSID. Este no fue un ejemplo sintético, pero Broadcom lo ha implementado para sus dispositivos bluetooth. Así que confían en que pueden agregar cualquier nombre base.

Aparte del hecho de que los SSID no tienen nada que ver con Bluetooth, EEE 802.11 define claramente un SSID como cualquier secuencia de bytes de hasta 32 bytes de longitud. Entonces, o bien Broadcom ya hace algún preprocesamiento para manejar cero bytes o su código ya tiene errores. En cualquier caso, este es claramente un caso de uso para codificar bytes cero en nombres de base de claves.

En cualquier caso, no tengo idea de las posibles extensiones futuras del conjunto de caracteres especiales, pero para el conjunto actual, creo que la solución implementada en # 3115 podría funcionar como está.

Si probamos el escenario de https://github.com/ElektraInitiative/libelektra/issues/2698#issuecomment -554680422 en esta versión, sucede lo siguiente:

Llamar a keyAddBaseName (key, "#_10") da como resultado que la última parte de key->key y de key->ukey sea #_10 . ¿Por qué? Porque #_10 es un elemento de matriz válido. Sí, si #_10 fuera un SSID, no lo veríamos como un elemento de matriz, pero el globbing con # lo igualaría, pero ¿eso realmente importa?

Si tomamos un elemento de matriz no válido como #10 o #abc , keyAddBaseName escapará y la última parte del nombre sin escape será #10 o #abc , mientras que la última parte del nombre de escape será \#10 o \#abc .

Todavía no he pensado en las reglas teóricas que necesitamos para que esto funcione para futuras extensiones, pero por ahora creo que podemos dejarlo así. Sería bueno tener elementos de matriz sin el carácter inicial, pero ¿realmente importa? Los complementos de almacenamiento son gratuitos para codificar matrices de manera diferente, si tienen un problema con el carácter # y para la línea de comandos, deberíamos simplemente agregar kdb array* comandos que toman parámetros enteros normales, por ejemplo, kdb arrayset /my/array 10 a .

Por cierto. tal vez sea mejor si nos vemos, por ejemplo, el martes?

El martes es malo para mí ... te enviaré un correo electrónico.

Aparte del hecho de que los SSID no tienen nada que ver con bluetooth,

Me refiero a dispositivos Blueray (que tienen capacidad wifi).

EEE 802.11 define claramente un SSID como cualquier secuencia de bytes de hasta 32 bytes de longitud. Entonces, o bien Broadcom ya hace algún preprocesamiento para manejar cero bytes o su código ya tiene errores. En cualquier caso, este es claramente un caso de uso para codificar bytes cero en nombres de base de claves.

Sí, tiene usted razón. Pero es una característica nueva. Cualquier cadena en keySetBaseName no es una característica nueva.

Porque # _10 es un elemento de matriz válido. Sí, si # _10 fuera un SSID, no lo veríamos como un elemento de matriz, pero el globbing con # coincidiría con él, pero ¿eso realmente importa?

No, eso no importa.

Sería bueno tener elementos de matriz sin el carácter inicial, pero ¿realmente importa?

No, lo más importante es que cualquier cadena se puede alimentar a keySetBaseName, y keyBaseName devuelve lo que se introdujo antes. Con la necesidad de caracteres iniciales en matrices, definitivamente puedo (y felizmente) vivir.

[...] y para la línea de comandos deberíamos simplemente agregar comandos kdb array * que toman parámetros enteros normales, por ejemplo, kdb arrayset / my / array 10 a.

Parece un buen plan.

Después de reexaminar todo, creo que solo hay un conflicto. Las siguientes declaraciones a no se pueden unificar.

1. Una parte de clave sin escape puede contener cualquier byte que no sea cero.
2. Una subcadena de una parte clave sin escape puede determinar una propiedad de la parte clave sin escape.

En nuestro caso particular. La primera declaración se deriva de las garantías de keyBaseName et al. junto con el hecho de que no desea que keyAddBaseName rechace un argumento. Además, la propuesta "las partes clave no superadas que comienzan con # son siempre índices de matriz" es un caso especial de 2.

Esto esencialmente significa mantener 1, lo cual queremos, es necesario volver a verificar siempre una parte de clave sin escape completa, si desea probar una determinada propiedad. En particular, debe verificar la parte de clave completa sin escape para saber que es un índice de matriz. Me parece una situación lamentable, pero parece inevitable.

Esto también significa que todavía podríamos hacer todo el asunto de "las partes clave escapadas que consisten completamente en dígitos son índices de matriz". El efecto secundario sería que en el ejemplo de SSID keyAddBaseName (key, "#_10") resultaría en un nombre de escape que termina en /10 lugar de /#_10 . Pero como ya aceptó el hecho de que keyAddBaseName (key, "#abc") produce un nombre de escape que termina en /\#abc , ¿supongo que esto tampoco sería un problema?
Implementar esto sería una tarea más grande, por lo que sería un PR de seguimiento al # 3115. Necesitaría verificar que todo lo que funciona con índices de matriz realmente use el nombre sin escape, además de actualizar todo lo que crea claves con partes de matriz.

En realidad, 2. no es necesariamente necesario. También podemos almacenar una tercera cadena que contiene el nombre de base que se devolverá (tal vez solo entonces cuando sea realmente necesario para no desperdiciar demasiada memoria).

Implementar esto sería una tarea más grande

Esto no es bueno, también tenemos que terminar con esto de alguna manera. Tal vez la tercera cadena nos rescatará, podemos optimizar esto más tarde (si es necesario).

¿O hacemos una lista completa de requisitos priorizados en una decisión o los cumplimos? La decisión será útil de todos modos para que la gente entienda más adelante por qué lo hicimos así y qué requisitos sacrificamos por otros requisitos.

En realidad, 2. no es necesariamente necesario.

Como dije, fue una propuesta. Sería bueno tenerlo, pero desafortunadamente no funciona.

También podemos almacenar una tercera cadena que contiene el nombre de base que se devolverá (tal vez solo entonces cuando sea realmente necesario para no desperdiciar demasiada memoria).

Necesitaríamos almacenar una tercera versión completa del nombre de la clave, de lo contrario keySetBaseName (key, NULL) funcionaría correctamente.

En este momento, no hay muchas propiedades que pueda tener una pieza clave. Al menos no propiedades que sean interesantes en todo Elektra. "¿Es una parte de índice de matriz?" es de hecho el único en el que puedo pensar. Si en el futuro tenemos más propiedades (por ejemplo, si agregamos el concepto de "marcadores de posición contextuales" al núcleo), podemos pensar en optimizaciones.

Esto no es bueno, también tenemos que terminar con esto de alguna manera.

Lo sé, que es exactamente por eso que dije que no lo haría en el # 3115. Si decidimos que lo necesitamos, abriré otro RP. Este segundo RP será mucho trabajo y será un cambio rotundo. Sin embargo, debería ser un cambio de ruptura mucho más pequeño y (la mayoría) de los otros RP simultáneos no deberían verse afectados tanto como lo harán cuando fusionemos # 3115.

¿O hacemos una lista completa de requisitos priorizados en una decisión o los cumplimos?

Escribiré documentación, incluida una decisión, cuando el código de # 3115 esté listo. La pregunta abierta en este momento es:

1. Aparte de / y \ , ¿qué caracteres pueden tener un significado especial al comienzo de una parte clave?
   En # 3115, estos son actualmente # , % , . y @ .
2. ¿Cuál es el significado especial? Esto puede ser diferente dependiendo del resto de la parte clave.
   En el # 3115 tenemos lo siguiente:
   
   
   
   • # significa parte de la matriz, si el resto de la parte clave son solo dígitos o primero n guiones bajos y luego n + 1 dígitos ( n >= 0 ) y nada más. Una parte de solo # no tiene un significado especial en general (puede significar un agrupamiento de matrices en algunas partes de Elektra). Cualquier otra parte que comience con # significa que el nombre de la clave no es válido.
   
   
   • % significa parte vacía si la parte es solo % . Cualquier otra parte que comience con % significa que el nombre de la clave no es válido.
   
   
   • . tiene un significado especial solo si la pieza es solo . o exactamente .. . Todas las demás partes que comienzan con . actualmente no tienen un significado especial, es decir, el nombre de la clave no es inválido. (Anteriormente, una parte que comenzaba con . hacía que una clave estuviera inactiva)
   
   
   • @ está reservado. Cualquier parte que comience con @ significa que el nombre de la clave no es válido.
   
   
3. ¿Debe permitirse siempre escapar de los caracteres especiales de 1 o solo cuando sea necesario?
   En # 3115 siempre se permite escapar.
4. ¿Queremos que las partes clave que constan completamente de dígitos se interpreten como partes de matriz? Si es así, ¿cuál es la representación canónica? Solo dígitos también, comenzando con # luego solo dígitos o lo mismo que la versión sin escape, es decir, # y guiones bajos?
   En # 3115 siempre requerimos que las partes de la matriz comiencen con # y su representación canónica es la misma que la sin escape.

Mis respuestas sugeridas son:

1. # , % , . , @ , $ , & y ? deben ser suficiente para posibles usos futuros. En particular, creo que no deberíamos reservar _ que solo causarán problemas.
2. Como lo tenemos en el # 3115. $ , & y ? están reservados para uso futuro como @ .
3. Siempre permitido.
4. Personalmente, estoy en contra de eso. Tener el carácter inicial hace que sea más fácil detectar las partes de la matriz al buscar nombres de clave. Como se sugiere en # 2698, cualquier colisión con caracteres especiales en formatos de almacenamiento debe resolverse mediante complementos de almacenamiento, no el núcleo, y la herramienta kdb solo debe tener comandos de matriz especiales.

Algo ligeramente no relacionado: podría ser posible convertir directoryvalue en una biblioteca (o incluso convertirla en parte del núcleo) y darle una interfaz privada que permita crear claves que no serían posibles a través de la API pública. Entonces no tendríamos que preocuparnos por las colisiones debido al nombre __directoryvalue . Uno de los caracteres reservados se usaría para eso. No he pensado mucho en ello, pero podría ser una buena idea, ya que la mayoría de los formatos de almacenamiento son buenos para la legibilidad humana, no admiten claves con un valor y claves a continuación.

Aparte de / y \, ¿qué caracteres pueden tener un significado especial al comienzo de una parte clave?
En # 3115 estos actualmente son #,%,. y @.

De esto se trata básicamente este tema: de recopilar personajes que potencialmente tienen un significado especial (ahora o reservado).

¿Debe permitirse siempre escapar de los caracteres especiales de 1 o solo cuando sea necesario?

Sí, siempre se permitirá.

¿Queremos que las partes clave que constan completamente de dígitos se interpreten como partes de matriz? Si es así, ¿cuál es la representación canónica? ¿Solo dígitos también, comenzando con un # y luego solo dígitos o lo mismo que en la versión sin escape, es decir, # y guiones bajos?

Esto depende en gran medida de las propiedades de los nombres base que perdamos. Desde la perspectiva del usuario, es "bueno" si no se necesita # , desde la perspectiva de la API es muy importante que keySet/AddBaseName simplemente funcione.

En particular, creo que no debemos reservarnos, eso solo causará problemas.

¿Y cambiar el globbing a * ?

Tener el carácter inicial hace que sea más fácil detectar las partes de la matriz al buscar nombres de clave.

No creo que sea un gran problema: los números dentro de una cadena también son bastante fáciles de detectar:

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

Entonces no tendríamos que preocuparnos por las colisiones debido al nombre __directoryvalue.

Si se implementa correctamente, no tenemos que preocuparnos también si se implementa como complemento, el complemento podría escapar ya presente __directoryvalue.

Mi sueño es que keySetBaseName escaparía de _directoryvalue (un guión bajo o @ sería suficiente), pero el complemento de valor de directorio usaría keyAddName para obtener un _directoryvalue sin formato dentro del nombre de la clave. (Lo cual estaría protegido porque el guión bajo o @ es un carácter reservado que no debe usarse para aplicaciones).

Ojalá podamos discutir esto hoy, espero que de esta manera podamos llegar más fácilmente a la conclusión.

Esto depende en gran medida de las propiedades de los nombres base que perdamos.

Como dije, no deberíamos perder nada en comparación con el estado actual del # 3115, pero tampoco necesariamente ganaríamos mucho. La pregunta principal es cuánto trabajo más queremos invertir en el cambio de nombre de la clave. Hablemos de esto hoy.

¿Y cambiar el globbing a * ?

* ya tiene significado para la biblioteca globbing. Significa cualquier parte clave. # solo coincide con partes de la matriz y _ coincide con partes que no son de matriz.

No creo que sea un gran problema: los números dentro de una cadena también son bastante fáciles de detectar

Este podría ser solo yo, pero no vi el /1/ al principio.

Si se implementa correctamente, no tenemos que preocuparnos también si se implementa como complemento, el complemento podría escapar ya presente __directoryvalue.

Vea # 3256 para una solución alternativa usando metakeys.

Mi sueño es que keySetBaseName escaparía de _directoryvalue

Estoy firmemente en contra de eso. El núcleo no debe preocuparse de ninguna manera por lo que hacen los complementos o los requisitos que tienen. También sienta un mal precedente. ¿Qué pasa si otro complemento usa _averyspecialkey para algo? ¿Vamos a actualizar keySetBaseName cada vez que esto suceda?

Resultado de la charla:

• las propiedades del nombre base ya parecen ser más o menos como antes
• las matrices continuarán comenzando con # (pero _ no serán necesarias)
• los caracteres de arriba se escaparán si están en la primera posición, excepto: #
• keySetBaseName no se actualizará y no se puede actualizar para nuevos caracteres, la lista anterior (cuando esté finalizada) es una lista completa para Elektra 1.0

los caracteres de arriba se escaparán si están en la primera posición, excepto: #

El comportamiento actual (en # 3115) de keySetBaseName y keyAddBaseName está definido por esta función:

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

Solo escapamos cuando es necesario para evitar un escape innecesario en nombre del escape.

Además, como preguntaste, si hay una relación 1: 1 entre el nombre de clave con escape y sin escape:

No no hay. Decidimos permitir un escape innecesario:

¿Debe permitirse siempre escapar de los caracteres especiales de 1 o solo cuando sea necesario?

Sí, siempre se permitirá.

Esto significa que, por ejemplo, /key/%abc y /key/\%abc son nombres de clave con escape diferentes para el mismo nombre de clave sin escape. Es decir, el que tiene un espacio de nombres en cascada y las dos partes key y %abc .

Si queremos asegurar una relación 1: 1, podríamos decir que el escape solo está permitido cuando sea necesario (no me gusta eso), o eliminar barras invertidas innecesarias durante el paso de canonicalización.
En cualquier caso, la relación 1: 1 requiere que keySetBaseName y keyAddBaseName comporten como se describió anteriormente, es decir, debe saber cuándo es necesario escapar.

Personalmente, no creo que se requiera la relación 1: 1. Solo necesitamos una relación: 1 para que ksLookup funcione. Normalmente no debería ser un problema, si buscamos /key/\%abc y recuperamos /key/%abc o viceversa.

Gracias por investigar el comportamiento de ida y vuelta. Sí, la búsqueda no es un gran problema (ya es 1: n debido a la conexión en cascada) pero las claves con diferentes nombres se eliminan cuando agregarlas al conjunto de claves es feo. Y, por supuesto, que no sea de ida y vuelta es otro objetivo importante: cada KeySet debe ser exactamente el mismo después de serializar y serializar, y esto no se daría si \% y % son "idénticos "en la representación interna.

¿Tiene quizás una solución al problema de ksAppend y de ida y vuelta?

Es una cuestión de definición. ¿Qué identifica de forma única una clave?

La respuesta técnica es el nombre sin escape. Es lo que utiliza un conjunto de claves para diferenciar entre claves.
Los usuarios solo tienen que acostumbrarse a saber cuándo dos nombres de clave son iguales. Es algo parecido a detectar que las fracciones 2/3 y 4/6 son iguales.

Si aún desea la relación 1: 1, el escape solo debe permitirse cuando sea necesario. Eso no supone un mayor esfuerzo de implementación, pero puede resultar molesto para los usuarios.

Es una cuestión de definición. ¿Qué identifica de forma única una clave?

Hasta ahora, decir "el nombre identifica una clave" era suficiente porque había 1: 1 entre escapado y no escapado. Solo se almacenaron ambos como mejora del rendimiento. (espacio contra tiempo)

Preferiría que se mantuviera así.

Si aún desea la relación 1: 1, el escape solo debe permitirse cuando sea necesario. Eso no supone un mayor esfuerzo de implementación, pero puede resultar molesto para los usuarios.

¿Por qué sería molesto?

Mi idea de \#123 vs #123 era que no es el mismo nombre de clave y no tiene el mismo significado (uno significa el literal #123 , el otro es el 124th entrada de matriz). Ambos tendrían diferentes nombres fugados y no fugitivos.

Si ahora tienen el mismo nombre sin escape, simplemente podemos rechazar keyAddName(k, "\\#123") . No hay ningún beneficio de tenerlo, ¿o sí?

Mi idea de \#123 vs #123 era que no es el mismo nombre de clave y no tiene el mismo significado (uno significa el literal #123 , el otro es el 124th entrada de matriz). Ambos tendrían diferentes nombres fugados y no fugitivos.

Ese ejemplo no demuestra nada. Obviamente, \#123 y #123 tienen diferentes versiones sin escape, de lo contrario no sería posible obtener la parte sin escape #123 de ninguna manera.

Las matrices también son un mal ejemplo, porque dijimos que # debe introducir una parte de matriz válida o se debe escapar, para evitar errores fáciles. En su lugar, veamos % .

Si la parte con escape es /%/ , obtenemos una parte sin escape vacía y si es /\%/ obtenemos la parte sin escape % . Obviamente, ambos deben ser partes clave de escape válidas. Hasta aquí todo bien.
La pregunta ahora se refiere a las partes /%abc/ y /\%abc/ . Ambos se asignan a la parte sin escape %abc . ¿Están permitidos ambos o uno de ellos no es válido? Si ambos están permitidos, no tenemos una relación 1: 1.

Esto es lo que quise decir con:

¿Debe permitirse siempre escapar de los caracteres especiales de 1 o solo cuando sea necesario?

A lo que respondiste:

Sí, siempre se permitirá.

Lo que interpreté como /%abc/ y /\%abc/ están permitidos. Ahora me doy cuenta de que podría haber querido decir "Sí, siempre obligatorio", es decir, solo /\%abc/ es válido.

De todos modos...
Tenemos dos opciones aquí:

1. Un carácter reservado debe introducir una parte válida con un significado especial, o se debe escapar.
   En el ejemplo anterior, esto significa que solo /\%abc/ es válido.
2. Un carácter reservado solo se debe escapar, cuando la parte tendría un significado especial sin el escape.
   En el ejemplo anterior, esto significa que solo /%abc/ es válido.

La elección se puede realizar de forma independiente para cada uno de los caracteres reservados. Solo se puede elegir una de estas opciones por carácter para mantener la relación 1: 1.

En # 3115, actualmente es la opción 1 por # y la opción 2 por . y % . Para @ ambas opciones son iguales, siempre requiere escapar. No hay piezas válidas que comiencen con @ . Tendré que comprobar que todo lo demás sea correcto, pero creo que ahora mismo tenemos una relación 1: 1 en el nº 3115.

Gracias por la explicación detallada. Sí, no es tan importante que /%abc/ se pueda escapar con una sola barra invertida. El viaje de ida y vuelta es mucho más importante. También podemos usar algo más para escapar de esto (en la capa de arriba).

No hay partes válidas que comiencen con @.

¿Cómo funcionará cuando asignemos @ un significado?

Tendré que comprobar que todo lo demás sea correcto, pero creo que ahora mismo tenemos una relación 1: 1 en el nº 3115.

Gracias: 100:

¿Cómo funcionará cuando le asignemos un significado a @?

Tiene razón, para asegurar la compatibilidad futura, tenemos que elegir la opción 1. Es fácil de ver:
/\%abc/ , /%/ y /\%/ son válidos, pero /%abc/ no lo es. Todas las partes que comienzan con @ no son válidas en este momento, pero las que comienzan con \@ están permitidas y seguirán siendo correctas, si algunas partes que comienzan con @ vuelven válidas.

Eliminé el conjunto de reglas que publiqué antes, porque después de jugar con una gramática ANTLR noté que las reglas no ayudan. Creo que tener una relación 1: 1 Y garantizar la compatibilidad con versiones anteriores al dar significado a los caracteres reservados es básicamente imposible.

Tomemos @ como ejemplo. Actualmente, solo las partes que comienzan con \@ son válidas, las que comienzan con @ siempre no son válidas. Partes de la forma \@XYZ ( XYZ es arbitrario) no se escapan en @XYZ .

Ahora decidimos introducir el significado de @ . Todas las partes de la forma @XYZ ( XYZ arbitraria) para las que el predicado foo(XYZ) ( foo es un predicado de cadena) es verdadero ahora no se escapan en bar(XYZ) ( bar es una función que asigna cadenas a cadenas). Para mantener la relación 1: 1, obviamente debemos asegurarnos de que ninguna otra parte quede sin escape en bar(XYZ) . Pero eso significa que algunas claves actualmente válidas dejarán de ser válidas, porque actualmente es posible obtener claves con nombres arbitrarios sin escape. Esto rompe la compatibilidad. (Nota: Podría ser posible mantener la relación 1: 1 y el comportamiento de ida y vuelta suelto entre las versiones "sin significado para @ " y "significado para @ ", pero eso es solo un diferente cambio de ruptura.)

Puede que tenga una solución para esto, pero ya sé que no te gustará, ya que implica no permitir ciertos nombres sin escape.

La explicación de mi solución se hizo bastante larga, así que la puse en un archivo en # 3115.

La idea básica es:

• Ya no todas las secuencias de bytes son nombres de clave sin escape. Algunas cadenas C ya no son partes válidas de nombres de clave sin escape.
• Esto hace posible una relación 1: 1 a prueba de futuro de nombres de claves con escape y sin escape. Las cadenas pueden convertirse en partes clave válidas sin escape, pero una vez que una cadena es válida, ya no puede volverse inválida.

La explicación detallada y lo que significa se puede encontrar aquí . Puede agregar comentarios aquí: https://github.com/ElektraInitiative/libelektra/commit/86d8e7806bfb92e95a7c519e09e95fa278eadb05

¡Muchas gracias por trabajar en esto! @sanssecours, ¿podrías echarle un vistazo si también te gusta la idea?

Puede que tenga una solución para esto, pero ya sé que no te gustará, ya que implica no permitir ciertos nombres sin escape.

Por cierto. no es que "no me gustará", es que a nadie le gustará Elektra si todos los complementos de almacenamiento tienen errores porque no pueden aceptar algunas cadenas.

tienen errores porque no pueden aceptar algunas cadenas

No tiene errores, si lo definimos de esa manera. JSON requiere un escape similar a C-strings. Nadie se queja de eso. Cualquier complemento de Elektra que use JSON solo requeriría usar algunos escapes más.

Si bien debería ser visible en las definiciones más detalladas, tal vez debería haber declarado explícitamente que no se pierde ninguna funcionalidad real. Es un poco más complicado en algunos casos.

Para cada secuencia de bytes, todavía hay un único nombre de clave sin escape que representa esta secuencia de bytes. Es solo que la secuencia original de bytes y el nombre de clave sin escape que la representa ya no serán siempre los mismos.

No tiene errores, si lo definimos de esa manera. JSON requiere un escape similar a C-strings. Nadie se queja de eso. Cualquier complemento de Elektra que use JSON solo requeriría usar algunos escapes más.

Estás comparando manzanas con plátanos aquí. JSON es un formato de serialización, estamos discutiendo una estructura de datos aquí (KeySet). En el nivel de serialización, los complementos de almacenamiento aún necesitan escapar / eliminar los nombres de clave y los valores de clave para que se puedan distinguir los separadores.

Si bien debería ser visible en las definiciones más detalladas, tal vez debería haber declarado explícitamente que no se pierde ninguna funcionalidad real. Es un poco más complicado en algunos casos.

Sin API es difícil saber qué significa "un poco más complicado".

Es solo que la secuencia original de bytes y el nombre de clave sin escape que la representa ya no serán siempre los mismos.

Creo que podríamos vivir con eso.

Solo me preocupa que este cambio sea demasiado grande (parece que también se necesitará una modificación en todos los complementos de almacenamiento) y no podremos finalizarlo. ¿Quizás es mejor olvidar la clasificación natural que trajo la mayor parte de este problema?

¿Quizás es mejor olvidar la clasificación natural que trajo la mayor parte de este problema?

La clasificación natural no tiene nada que ver con esto. AFAIK, ni siquiera se menciona en ninguna parte de la propuesta. El problema consiste en invertir caracteres para uso futuro y evitar cambios importantes.

Sin API es difícil saber qué significa "un poco más complicado".

La API está en la propuesta. En este caso, "un poco más complicado" solo significa elegir entre dos operaciones ( pushL y pushU , los nombres son marcadores de posición) en lugar de usar siempre la misma ( keyAddBaseName ). Y, a veces, ignorar una barra invertida al comparar partes clave con cadenas.

Solo me preocupa que este cambio sea demasiado grande

Por supuesto que es un gran cambio, pero reducirá futuros cambios importantes.

no podremos terminarlo

Bueno, eso depende completamente de la fecha límite ...

Como hemos comentado, creo que deberíamos olvidarnos de este tema (reserva de caracteres especiales). En su lugar, el escape de nivel superior (como matrices # , % ) o la reserva de caracteres especiales ( @ ) debe realizarse directamente en los complementos de almacenamiento.

Bueno, eso depende completamente de la fecha límite ...

Si desea hacer una tesis de maestría sobre bibliotecas de software preparadas para el futuro, puede volver a abrir este tema: guiño:

Como se discutio [...]

Eso no es lo que recuerdo de la discusión. Pensé que habíamos acordado terminar el # 3115 y luego pensar en este tema nuevamente.

Terminaré el # 3115 y también agregaré algunos ejemplos y explicaciones en un lenguaje sencillo a la propuesta.

En su lugar, el escape de nivel superior (como matrices #,%) o la reserva de caracteres especiales (@) deben realizarse directamente en los complementos de almacenamiento.

Esta es francamente una solución estúpida ...

Cada vez que agreguemos algo nuevo a los nombres de las claves, tendremos que actualizar todos los complementos de almacenamiento. Esa es exactamente la razón por la que usó contra mi solución (que solo requiere esto una vez).

Tampoco evita la actualización de los complementos ahora, ya que, AFAIK, ninguno de ellos maneja nombres de clave 100% correctos (partes de matriz).

Si realmente no quiere mi propuesta, por favor dé una razón en contra de ella, en lugar de proponer una solución que no resuelve nada y es casi tanto esfuerzo.

Si desea hacer una tesis de maestría sobre bibliotecas de software preparadas para el futuro

No, no quiero hacer eso ... solo quiero hacer que los nombres clave de Electra sean a prueba de futuro, lo cual es una tarea mucho más pequeña y simple.

Eso no es lo que recuerdo de la discusión. Pensé que habíamos acordado terminar el # 3115 y luego pensar en este tema nuevamente.

Sí, no terminamos la discusión pero:

• Mi recomendación es corregir otros errores importantes y problemas de usabilidad.
• De todos modos, no puedo prohibirle que lo piense: guiño:

Tampoco evita la actualización de los complementos ahora, ya que, AFAIK, ninguno de ellos maneja nombres de clave 100% correctos (partes de matriz).

Informe los errores. El uso de matrices como se especifica en doc / decision / array.md debería ser correcto. Entonces #0 es un "nombre simple sin significado" y las matrices solo adquieren significado con una clave directamente debajo que tiene metadatos "matriz".

Si realmente no quiere mi propuesta, por favor dé una razón en contra.

Me gusta mucho la propuesta. Pero cosas como # 1074 (y ver https://github.com/ElektraInitiative/libelektra/projects/9 para más) son en mi humilde opinión mucho más críticas para el éxito de Elektra.

en lugar de proponer una solución que no resuelve nada y que supone tanto esfuerzo.

¿Qué quieres decir? Mi última propuesta fue simplemente no reservar caracteres y dejar que los complementos de almacenamiento hagan lo que quieran. No veo ningún esfuerzo en "implementar" esta propuesta (es un NOP).

No, no quiero hacer eso ... solo quiero hacer que los nombres clave de Electra sean a prueba de futuro, lo cual es una tarea mucho más pequeña y simple.

Quizás esto ya sea suficiente para una tesis de maestría si terminas las pruebas. Sin embargo, no busqué trabajo relacionado, tal vez alguien más ya hizo algo como esto.

El uso de matrices como se especifica en doc / decision / array.md debería ser correcto.

Ese podría ser el caso, pero el tutorial para complementos de almacenamiento no está de acuerdo e incluso muestra que yamlcpp no funciona de esta manera.

Pero cosas como el # 1074 son en mi humilde opinión mucho más críticas para el éxito de Elektra.

Me preocupan los cambios en los nombres clave, porque eso es lo que ya estoy haciendo y tengo mucha información en este momento. Además, ya tenemos un cambio importante en los nombres de las claves, por lo que no importa mucho si rompemos más cosas.

Los puntos de montaje de usuario / directorio serían agradables, sí, pero no tengo idea de cómo resolver eso. Probablemente me tomaría tanto tiempo o más encontrar e implementar una solución, ya que me llevaría implementar mis cambios propuestos en los nombres de las claves.

Mi última propuesta fue simplemente no reservar personajes

Mencionaste reservar @ .

dejar que los complementos de almacenamiento hagan lo que quieran

Eso solo conduce a incompatibilidades. Por supuesto, no podemos evitar que los complementos de almacenamiento utilicen un formato completamente diferente, pero no dar ninguna guía es solo pedir problemas.

Ese podría ser el caso, pero el tutorial para complementos de almacenamiento no está de acuerdo e incluso muestra que yamlcpp no ​​funciona de esta manera.

@sanssecours, ¿puedes investigar esto? Si reconocemos las matrices solo por la estructura (nombres con #0 ), el KeySet no se inclinará.

Probablemente me tomaría tanto tiempo o más encontrar e implementar una solución

Sí, pero el punto de montaje de usuario / directorio es algo con lo que todos los usuarios de Elektra se enfrentan con frecuencia. Si alguna vez necesitamos caracteres reservados, no se sabe.

Mencionaste reservar @.

Sí, los complementos de almacenamiento pueden reservar y escapar lo que quieran.

Eso solo conduce a incompatibilidades. Por supuesto, no podemos evitar que los complementos de almacenamiento utilicen un formato completamente diferente, pero no dar ninguna guía es solo pedir problemas.

Estoy de acuerdo completamente. Quizás algunas personas en algunos años nos odien por no reservar algunos personajes (pero quizás tampoco). Pero estoy bastante seguro de que no contribuirá al éxito de Elektra 1.0. Para ser claros: no estoy totalmente en contra de implementarlo, pero otras cosas (https://github.com/ElektraInitiative/libelektra/projects/9) están en mi humilde opinión mucho más arriba en la lista de prioridades. Usted es libre de estar en desacuerdo e implementarlo de todos modos. No rechazaría el PR siempre que no se vuelva demasiado complicado para los complementos de almacenamiento (y todos los complementos se arreglen). Pero existe un alto riesgo de que otras cosas (que son esenciales para el éxito) no se implementen y Elektra no se utilice en proyectos importantes como KDE.

@sanssecours, ¿puedes investigar esto? Si reconocemos las matrices solo por la estructura (nombres con #0 ), el KeySet no se inclinará.

Actualicé el comportamiento de YAML CPP y el complemento Directory Value en PR 3357. La solicitud de extracción también actualiza parte de la documentación para tener en cuenta los metadatos obligatorios array .

Ahora he actualizado la propuesta en # 3447. Espero que ahora sea más fácil de entender (todavía es muy largo).

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

@ markus2330 Voy a poner esto aquí aunque la discusión anterior fue en # 3223, porque creo que encaja mejor.

Acabo de descubrir / recordar que en la versión actual de Elektra [1], ya es el caso (e implementado de esa manera) que "cualquier parte del nombre de clave ESCAPED que comience con @ invalida toda la clave". Esto significa que podríamos, sin implementar ninguno de los otros cambios de la propuesta, usar nombres de campo que comiencen con @ para propósitos especiales en complementos de almacenamiento, como sugiere la propuesta con $meta y $value .

@ bauhaus93 Esto podría ayudarlo cuando implemente y metadatos en toml (y también para claves de valor no hoja, hasta cierto punto).

Para aquellos que no han leído la propuesta, la idea sería esencialmente (para JSON):

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

Se convierte en dos llaves:

key = 127.0.0.1
key/sub = xyz

y key también tiene estos metadatos:

check/ipaddr = ipv4

~ Dado que tanto key/@value como key/@meta son nombres de claves reservados (o incluso no válidos en # 3447), esto no puede causar ningún conflicto. ~

[1] master solo menciona esto en la documentación , pero le permite crear dichas claves. # 3447 por otro lado ~ prohíbe estas claves por completo ~ requiere que @ se escape al comienzo de las partes del nombre de clave en nombres de clave escapados. La documentación también tiene una disposición similar para _ , pero eso tampoco se aplica en # 3447.

Perdón por la confusión, pero tuve que aclarar partes del comentario anterior. La parte sobre @ solo se aplica al nombre de clave escapado. El nombre sin escape (como C-String) "\01\00key\00@meta\00" sigue siendo válido en # 3447, como siempre. Esto significa que @meta no se puede usar para metadatos sin más consideraciones en el complemento de almacenamiento.

Sin embargo, dado que siempre ha sido un nombre reservado y necesitaremos escapar en # 3447, creo que aún es justo usarlo en un complemento de almacenamiento. En mi opinión, un usuario no debe esperar que un nombre reservado siempre se pueda utilizar sin problemas. Pero, por supuesto, tendremos que tomar algunas precauciones. Una posibilidad sería esta (JSON nuevamente):

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

Se convierte en dos claves (tenga en cuenta el \ para escapar):

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

Pero esto

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

Se convierte en (nuevamente \ por escapar):

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

Las reglas aquí serían:

• el nombre del campo no comienza con @ -> use el nombre del campo y agregue con keyAddBaseName
• el nombre del campo comienza con más de un @ -> elimine un primer @ y use el resto para keyAddBaseName
• el nombre del campo comienza con un solo @ -> compruebe si el nombre del campo tiene un significado especial (por ejemplo, @value o @meta ):
  
  
  
  • si tiene un significado especial, procese en consecuencia
  
  
  • de lo contrario, use el nombre del campo para keyAddBaseName (por ejemplo, @sub )
  
  

(Nota: keyAddBaseName toma un nombre sin escape y hace el escape requerido para mantener válido el nombre de la clave)

No entiendo el objetivo de los dos últimos comentarios, ¿es esta una propuesta sobre el reemplazo del complemento de valor de directorio?

(tenga en cuenta la \ para escapar)

Para @ usualmente usamos @ para escapar, así que simplemente descarte el primer @ si hay varios. Sería bueno si esto también se documentara en la descripción del nombre de la clave. Podríamos cambiar a \ (si hace que el escape de los nombres de clave en general sea más fácil de entender) pero esto necesita cambios al menos en el complemento base64. (el complemento nulo se elimina en # 3491)

No entiendo el objetivo de los dos últimos comentarios, ¿es esta una propuesta sobre el reemplazo del complemento de valor de directorio?

La parte @value es sí. Pero es más general. @meta podría usarse para almacenar metadatos dentro de un formato con una única estructura de objeto anidada, como JSON o TOML (todavía no estoy seguro de YAML, porque las etiquetas).
Básicamente, debido a que todo en el archivo JSON se refiere a alguna clave en algún lugar, simplemente no hay lugar para almacenar metadatos. A menos que imponga algunas limitaciones en la estructura del archivo JSON, probablemente no pueda simplemente montar algún archivo de configuración. [1]

Como dije, debe imponer restricciones para ajustar los metadatos en JSON (AFAIK, lo mismo ocurre con TOML). Entonces, sí, mi propuesta en los comentarios anteriores impone una restricción en los archivos JSON, pero las aplicaciones que usan @ al comienzo de un campo JSON probablemente sean bastante raras.

Para @ usualmente usamos @ para escapar, así que simplemente descarte el primer @ si hay varios. Sería bueno si esto también se documentara en la descripción del nombre de la clave. Podríamos cambiar a \ (si hace que el escape de los nombres de clave en general sea más fácil de entender) pero esto necesita cambios al menos en el complemento base64.

No estoy seguro de cómo el complemento base64 es relevante aquí, pero quiero ser muy claro:

En el actual master (6a1535c094c7be2f441bd0e7b0dda1c50e97ee1d) keyNew ("/elektra/@abc", KEY_END) funciona y crea un nombre sin escape con las partes elektra y @abc .
En # 3447 keyNew ("/elektra/@abc", KEY_END) devuelve NULL porque el nombre se considera inválido, pero keyNew ("/elektra/\@abc", KEY_END) funciona y crea un nombre sin escape con las partes elektra y @abc .
No estoy seguro de qué hace keyNew ("/elektra/\@abc", KEY_END) en el maestro.

keyAddBaseName (k, "@abc") funciona en ambos casos, la única diferencia es qué nombre de escape crea.

Tampoco recuerdo por qué hice este cambio. Probablemente hubo una buena razón, pero en cualquier caso ya está hecho y no creo que sea fácil volver a cambiar.

[1] Como siempre, el problema aquí es que Elektra quiere hacer todo y complacer a todos. Por un lado, queremos permitir complementos de almacenamiento que puedan leer archivos arbitrarios en un formato estándar (por ejemplo, JSON) y convertirlos en KeySets. Por otro lado, queremos permitir que las aplicaciones usen cadenas arbitrarias como parte de un nombre de clave. Esto podría funcionar durante algún tiempo, pero al menos cuando llega a los metadatos, se rompe para ciertos formatos.

JSON es un árbol único con valores solo en los nodos hoja. Los conjuntos de claves son un árbol con valores en cada nodo, y algunos de los nodos también tienen un enlace a un árbol completamente separado. Es posible que pueda convertir entre los dos, pero uno de ellos debe imponer limitaciones al otro para tener una conversión sin pérdidas.

Como dije, debe imponer restricciones para encajar los metadatos en

@kodebach, ¿esto significa que está a favor de restringir los formatos en los que se pueden almacenar los metadatos?

Nunca me topé con esto, porque usé principalmente dump y luego mmapstorage y rara vez importé / exporté configuraciones usando otros complementos. Esto es bastante lamentable. Como usuario, preferiría poder importar / exportar a especificaciones estándar (perdiendo metadatos) mientras se almacenan los datos reales (incluidos los metadatos) utilizando un formato interno elektra arbitrario.

Creo que restringir el formato puede resultar confuso para los usuarios. Por ejemplo, si Elektra proporciona un complemento JSON no experimental, esperaría que pudiera manejar entradas arbitrarias que cumplan con las especificaciones. No me queda claro cómo el usuario podría comprobar que sus archivos de configuración cumplen con las especificaciones restringidas.

@ markus2330 ¿qué opinas sobre la imposición de restricciones al formato?

EDITAR: Estoy de acuerdo en que "Elektra quiere hacer todo y complacer a todos" es un problema.

¿Significa esto que está a favor de restringir los formatos en los que se pueden almacenar los metadatos?

Necesitamos definir nuestras prioridades. Qué es exactamente una necesidad absoluta y dónde pueden cambiar las cosas. Como está ahora, la única forma para muchos formatos es almacenar metadatos en comentarios ( @ bauhaus93 hizo eso en # 3500 para TOML). En mi opinión, esta no es una solución, sino simplemente un trabajo torpe. La peor parte es que los abusos son la única parte que nunca debe tocar un analizador y puede afectar drásticamente la legibilidad de un archivo de almacenamiento. Algunos formatos (a saber, JSON) tampoco tienen comentarios.

Las restricciones muy básicas que podríamos imponer (usando JSON como ejemplo nuevamente) serían que todos los archivos deben verse así:

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

Otras "restricciones" incluyen interpretar ciertos nombres de clave como @meta de formas especiales y proporcionar métodos de escape.

El objeto kdb contiene las claves reales y meta contiene los metadatos. (Nota: para resolver claves que no son hojas con valores, necesitaría otro objeto)

En lugar de dos objetos JSON, también podríamos usar archivos separados. Pero eso necesitaría el apoyo de al menos el solucionador y tal vez incluso el código / complemento de backend. Los archivos separados permitirían importar archivos JSON estándar, sin metadatos. No está claro cómo se manejarían las claves que no son hojas con valores en este caso.

Como usuario, preferiría poder importar / exportar a especificaciones estándar (perdiendo metadatos) mientras se almacenan los datos reales (incluidos los metadatos) utilizando un formato interno elektra arbitrario.

Estoy de acuerdo, pero importar / exportar todo va un poco en contra de la idea del punto de montaje de Elektra.

Ya lo sé, nadie quiere implementar esto, pero hay una solución muy general:

Si un punto de montaje usa un complemento de almacenamiento que no es compatible con todas las funciones de Elektra, el complemento de backend crea un archivo de almacenamiento de respaldo secundario en un formato que admite todas las funciones (por ejemplo, quickdump , mmapstorage parece una pérdida de espacio en disco aquí). Al escribir un punto de montaje de este tipo, simplemente escribimos con ambos complementos. Al leer, primero leemos el archivo de respaldo secundario y luego el archivo principal. Esto requeriría un proceso de fusión, pero tomaremos el archivo principal como fuente de por lo que la fusión es bastante simple.

Creo que restringir el formato puede resultar confuso para los usuarios.

Definitivamente. Pero para mí está claro que actualmente Elektra permite mucho y algo tiene que estar restringido.

Incluso la solución con varios archivos requiere algún tipo de restricción para configurar los nombres de los archivos para evitar colisiones.

Originalmente pensé que la solución más fácil sería restringir los Nombres Clave de Elektra, ya que esa es la parte sobre la que tenemos más autoridad. Pero aparentemente hay aplicaciones que usan SSID WiFi [1] directamente como una parte de nombre de clave, por lo que no funciona. Al menos no sin un gran esfuerzo, como mostraba mi propuesta ...
OMI aún sería la mejor solución para todo esto para decir simplemente "clave nombrar las partes no son secuencias arbitrarias de no cero bytes más" y hacerse con él. A modo de comparación, POSIX solo permite los siguientes caracteres en los nombres de archivo:

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

Y eso parece ser suficiente para la gente. Todos los sistemas de archivos enumerados en Wikipedia (excepto los que no tienen directorios) tienen algún tipo de restricción en los nombres de los archivos.

Quiero enfatizar nuevamente: todo esto se reduce al hecho de que hemos tomado "Las partes de los nombres clave son secuencias arbitrarias de bytes distintos de cero" como axioma [2]. Cambiar esto sería muy fácil y arreglaría todo. Incluso podría ser una restricción pequeña, por ejemplo, "Las partes de nombre de clave son secuencias arbitrarias de bytes distintos de cero, excepto aquellas que comienzan con @$% y terminan en !%& al mismo tiempo".
Simplemente reservar una sola parte de nombre de clave, por ejemplo, "Las partes de nombre de clave son secuencias arbitrarias de bytes distintos de cero, excepto que !@& no lo es", nos daría muchas posibilidades. Diablos, incluso la restricción "la última parte del nombre de clave en un nombre de clave no debe terminar con @%& " debería ser suficiente. Cualquier tipo de restricción [3], por pequeña que sea, nos daría margen de maniobra para implementar todo tipo de cosas.
Por supuesto, muchas restricciones hacen posibles las soluciones, pero una solución buena y utilizable puede requerir restricciones más grandes.

Lo siento, si esto parece una perorata, pero en algún momento se vuelve realmente frustrante que todos estén de acuerdo en que hay un problema, pero se considera que cada solución tiene un defecto o se considera demasiado complicada.

[1] Según Wikipedia, hasta 802.11-2012, un SSID WiFi tenía "de cero a 32 octetos (32 bytes) de longitud", incluidos los bytes cero y "las pilas de redes inalámbricas deben estar preparadas para manejar valores arbitrarios en el campo SSID", incluso aunque los SSID ahora deben ser UTF-8 válidos. Por lo tanto, solo keyAddBaseName ing un SSID WiFi sin ninguna lógica adicional no sería compatible con los estándares de todos modos.

[2] Esa es la razón por la que la nueva documentación en # 3447 comienza con Key Name Parts. Es más fácil (y en mi opinión, el más lógico) explicar los nombres clave actuales comenzando con las partes del nombre clave y siguiendo desde allí. Pero la vieja forma de

tome una ruta del sistema de archivos Unix / POSIX y agregue un espacio de nombres, pero también hay algo especial como partes vacías y secuencias de escape, y luego está la versión sin escape: está semi-oculta pero probablemente debería usarse para todo además de la impresión, y las matrices son una cosa, también algunas partes están reservadas pero en realidad no están reservadas, por lo que en realidad no las usamos para nada de bajo nivel, ....

muestra mucho mejor lo increíblemente complejos y complicados que son los nombres clave.

[3] En caso de que se lo pregunte, sí # 3447 impone algunas restricciones nuevas, pero esas son inútiles, porque no afectan el Nombre de clave sin formato (excepto el espacio de nombres) de ninguna manera.

Los archivos separados permitirían importar archivos JSON estándar, sin metadatos. No está claro cómo se manejarían las claves que no son hojas con valores en este caso.

Discutimos esto con respecto a la implementación de la caché y decidimos no hacerlo. La implementación actual del resolutor tiene garantías de coherencia más sólidas que las que se pueden lograr cuando se utilizan dos archivos. El solucionador usa la función atómica rename() para garantizar que un proceso lea el archivo antiguo o el nuevo, pero siempre coherente. Desafortunadamente, esto no se puede (que yo sepa) hacerse con varios archivos mientras se tienen las mismas garantías. Sería reacio a usar varios archivos donde necesitamos garantizar la coherencia.

Estoy de acuerdo, pero importar / exportar todo va un poco en contra de la idea del punto de montaje de Elektra.

Cierto.

Todo esto se reduce al hecho de que hemos tomado "Las partes del nombre clave son secuencias arbitrarias de bytes distintos de cero" como axioma [2].

Estoy de acuerdo, esta es la parte donde las restricciones tienen más sentido. Como ha dicho, los nombres de archivo están bastante restringidos y todavía funciona muy bien. A menos que alguien sepa una buena razón para no restringir los nombres de clave (tal vez @ markus2330).

Lo siento, si esto parece una perorata

No, y gracias por discutir esto. A menos que @ markus2330 sepa algunas razones por las que no podemos cambiar esto, estoy completamente abierto a su sugerencia (como restringir !@& ).

Sería reacio a usar varios archivos donde necesitamos garantizar la coherencia.

Esa es una buena razón, contra varios archivos, sí ...

Estoy completamente abierto a tu sugerencia (como restringir !@& ).

De manera más realista, podríamos imponer la restricción: "Un nombre de clave no debe contener la parte del nombre de clave @elektra " (posiblemente un prefijo más oscuro, si eso ayuda). Creo que usar elektra podría hacer que todo sea un poco más razonable para los usuarios.

Personalmente, creo que deberíamos dejar espacio para el futuro, pero si restringir todos los Nombres Clave es demasiado, también podríamos restringir lo que kdbGet puede devolver y lo que kdbSet puede aceptar. Por lo tanto, la restricción anterior solo se aplicaría a lo que devuelve el último complemento durante kdbGet y al KeySet dado a kdbSet . Básicamente, solo restringiríamos las claves que se pueden almacenar desde el punto de vista de una aplicación. Esto sería similar a lo que ya tenemos con system:/elektra (aunque esta vez aplicaríamos la restricción).

Muchas gracias por estas valiosas discusiones. Empecé con el n. ° 3514 para resumir las decisiones importantes esparcidas por todas partes. Prefiera comentar directamente sobre el texto en # 3514, para que podamos llegar a conclusiones.

La parte @value es sí. Pero es más general. @meta podría usarse para almacenar metadatos dentro de un formato con una única estructura de objeto anidado, como JSON o TOML (todavía no estoy seguro acerca de YAML, porque las etiquetas).
Básicamente, debido a que todo en el archivo JSON se refiere a alguna clave en algún lugar, simplemente no hay lugar para almacenar metadatos.

Ya no creo que nuestro objetivo deba ser eludir las restricciones de los formatos de archivo. Si JSON no admite metadatos y valores no hoja, Elektra con un archivo JSON montado, simplemente reenvía sus restricciones en KeySets. Podemos documentarlos, como se propone en # 3504 y los complementos de almacenamiento deberían fallar en dichos KeySets, pero nada más. (Por supuesto, alguien puede crear un formato de archivo super-JSON con menos restricciones, pero esto está más allá de nuestra mano de obra actual y, como tal, es irrelevante).

pero las aplicaciones que usan @ al comienzo de un campo JSON probablemente sean bastante raras.

¿Quién sabe?

keyAddBaseName (k, "@abc") funciona en ambos casos, la única diferencia es qué nombre de escape crea.

Suena bien.

pero al menos cuando llega a los metadatos, se rompe para ciertos formatos.

Sí, debemos descartar la idea de que cualquier formato puede admitir cualquier cosa.

No me queda claro cómo el usuario podría comprobar que sus archivos de configuración cumplen con las especificaciones restringidas.

Creo que la mayoría de las aplicaciones no serán muy exigentes de todos modos (por ejemplo, solo tienen valores hoja y no necesitan metadatos excepto el tipo), por lo que todo lo que discutimos aquí solo es relevante para aplicaciones excepcionales. Para estas aplicaciones, creo que es mejor que los desarrolladores de aplicaciones desarrollen sus propios complementos de almacenamiento o utilicen nuestros mejores complementos de almacenamiento, que admiten este tipo de cosas.

@ markus2330 ¿qué opinas sobre la imposición de restricciones al formato?

No es una buena idea. Deberíamos admitir formatos de archivo de configuración estandarizados. Puede ser un gran problema si Elektra rechaza algunos archivos JSON / XML válidos. Pero, por otro lado, no necesitamos admitir nada más que estandarizado. Probar esto fue un error del pasado (intentar complacer a cualquiera).

Necesitamos definir nuestras prioridades. Qué es exactamente una necesidad absoluta y dónde pueden cambiar las cosas.

doc / GOALS.md en # 3514

La peor parte es que los abusos son la única parte que nunca debe tocar un analizador y puede afectar drásticamente la legibilidad de un archivo de almacenamiento.

Estoy de acuerdo en que no es la mejor idea, ya tenía muchos problemas en el complemento ini . badcec5407df6947a67750afd8f0946245c5a5bb

En lugar de dos objetos JSON, también podríamos usar archivos separados.

Vea abajo.

A modo de comparación, POSIX solo permite los siguientes caracteres en los nombres de archivo:

Este es el "conjunto de caracteres de nombre de archivo portátil" y dudo que haya algún sistema de archivos en uso que solo lo admita. En mi experiencia, cualquier interpretación de los nombres de los archivos solo genera problemas (por ejemplo, JFS tenía esas características).

Y eso parece ser suficiente para la gente.

Para la fuente de Elektra, casi es # 1615: guiño:

Pero las aplicaciones reales inmediatamente querían más ... (por ejemplo, espacios, diéresis, ....)

Cambiar esto sería muy fácil y arreglaría todo.

No es tan simple como eso: hace que los complementos de almacenamiento sean mucho más complicados. Simplemente traslada la lógica a otros lugares.

excepto aquellos que comienzan con @ $% y terminan en!% & al mismo tiempo

Esta idea es similar a CDATA . No es una solución bonita y difícil de usar en la práctica.

HERE son un poco mejores, ya que el usuario puede definir la secuencia de escape.

Pero, ¿para qué función crees exactamente que la necesitamos? Creo que deberíamos olvidarnos de estas características y utilizar correctamente los metadatos para dar semántica a las claves.

Lo siento, si esto parece una perorata, pero en algún momento se vuelve realmente frustrante que todos estén de acuerdo en que hay un problema, pero se considera que cada solución tiene un defecto o se considera demasiado complicada.

Mi punto es: tal vez no necesitemos una solución porque el problema no existe.

ahora debe ser válido en UTF-8

¿Todavía pueden tener caracteres nulos? Por cierto. Se me ocurrió el ejemplo de SSID porque este era un requisito real de un cliente real (broadcom). No se requieren caracteres nulos, es obvio que un char* sin tamaño no puede admitir esto, por lo que ni siquiera discutimos sobre esto.

muestra mucho mejor lo increíblemente complejos y complicados que son los nombres clave.

Sí, pero es mejor que sean así que tener esa lógica en cada aplicación y complemento de almacenamiento.

En caso de que se lo esté preguntando, sí # 3447 impone alguna nueva restricción

Sí, el nombre de la clave puede tener restricciones. Siempre existió la restricción de escapar colgando, por lo que algunas restricciones más no importan. # 3447 será una gran mejora para Elektra.

Desafortunadamente, esto no se puede (que yo sepa) hacerse con varios archivos mientras se tienen las mismas garantías

Puede hacerlo escribiendo un registro de diario en el que escriba todo lo que planea hacer y, en caso de problemas, puede recuperarse reproduciendo el diario. Implementar esto está mucho más allá de nuestra mano de obra. Tampoco encaja realmente en un sistema de configuración (ni sistemas de archivos), es una técnica para bases de datos estructuradas.

Lo convertí en un no objetivo en multiple_file_backends.md 59066aa99bae707d0f0178841513fd3b8590b5bc

Básicamente, solo restringiríamos las claves que se pueden almacenar desde el punto de vista de una aplicación. Esto sería similar a lo que ya tenemos con system: / elektra (aunque esta vez aplicaríamos la restricción).

Podemos hacer cumplir la restricción de system:/elektra . Pero, ¿por qué quiere restringir qué aplicaciones se almacenan en su parte de su jerarquía?

Creo que es mejor que los desarrolladores de aplicaciones desarrollen sus propios complementos de almacenamiento.

De este modo, se derrota uno de los principales beneficios de Elektra: "El administrador / usuario decide el formato de configuración, no el desarrollador de la aplicación".

Puede ser un gran problema si Elektra rechaza algunos archivos JSON / XML válidos

Esa nunca fue mi sugerencia. Por supuesto, deberíamos aceptar todos los JSON válidos. La pregunta es qué KeySet producimos. Si usamos "@value" para valores que no son hojas como se sugirió anteriormente, aún podríamos aceptar todos los JSON válidos. El KeySet resultante tendría una estructura ligeramente diferente en algunas ocasiones.

A modo de comparación, POSIX solo permite los siguientes caracteres en los nombres de archivo:

Este es el "conjunto de caracteres de nombre de archivo portátil" y dudo que haya algún sistema de archivos en uso que solo lo admita. En mi experiencia, cualquier interpretación de los nombres de los archivos solo genera problemas (por ejemplo, JFS tenía esas características).

Y eso parece ser suficiente para la gente.

Para la fuente de Elektra, casi es # 1615

Pero las aplicaciones reales inmediatamente querían más ... (por ejemplo, espacios, diéresis, ....)

Todavía no permiten / o nombres vacíos. La mayoría también tiene longitudes máximas para nombres de archivo y rutas. El punto es que las aplicaciones encuentran formas de evitar las limitaciones. Y en nuestro caso incluso podemos ayudarles con bibliotecas.

No es tan simple como eso: hace que los complementos de almacenamiento sean mucho más complicados. Simplemente traslada la lógica a otros lugares.

No estoy de acuerdo. Los complementos de almacenamiento ya son extremadamente complejos, relativamente hablando, esto solo sería un inconveniente menor. (asumiendo que proporcionamos una buena biblioteca storage con funciones auxiliares)

Esta idea es similar a CDATA. No es una solución bonita y difícil de usar en la práctica.

Los documentos AQUÍ son un poco mejores, ya que el usuario puede definir la secuencia de escape.

Tanto los documentos CDATA como HERE necesitan reservar algo de sintaxis, desde el punto de vista actual de Elektra no hay diferencia. Ambas versiones son una restricción en los nombres de las claves.

Además, ambos son mucho más poderosos de lo que propuse. Mi propuesta sólo "escaparía" de una parte completa del nombre de la clave a la vez.

Creo que deberíamos olvidarnos de estas características y utilizar correctamente los metadatos para dar semántica a las claves.

Acaba de decir que algunos complementos de almacenamiento podrían no admitir metadatos. Entonces parece que esta no es una opción.

Mi punto es: tal vez no necesitemos una solución porque el problema no existe.

Por supuesto, si cambia de opinión y dice que un formato de almacenamiento puede limitar las capacidades de Elektra, el problema desaparece. Pero eso cambia fundamentalmente la promesa de Elektra a los usuarios. Limitaríamos a todos los usuarios solo para permitir que algún desarrollador guarde algunas líneas de código relacionadas con la codificación de valores especiales.

¿Todavía pueden tener caracteres nulos?

Probablemente, NUL es un carácter UTF-8 válido.

sin tamaño no puedo soportar esto

Bueno, el tamaño máximo de un SSID es de 32 bytes, por lo que no tiene que pasar el tamaño, siempre que el búfer sea siempre de 32 bytes y con relleno de ceros.

Sí, el nombre de la clave puede tener restricciones.

Por favor decídete. Todo este tiempo ha argumentado que no puede haber restricciones.

Siempre existió la restricción de escapar colgando, por lo que algunas restricciones más no importan.

El "escape colgante" no es una restricción. Es un error de sintaxis en el nombre de la clave de escape. Los nombres de claves escapados nunca fueron cadenas arbitrarias. Esto es algo totalmente diferente.

Podemos hacer cumplir la restricción de system:/elektra .

Podríamos requerir una bandera en keyNew para permitir tales nombres. De lo contrario, una aplicación que acepte nombres de claves del usuario tendría que desinfectar la entrada. Vea también el problema kdb import en # 3299.

Pero, ¿por qué quiere restringir qué aplicaciones se almacenan en su parte de su jerarquía?

No quiero restringir _qué_ aplicaciones se almacenan, pero _cómo_ lo almacenan. Esto le da a los complementos (de almacenamiento) más libertad.

De este modo, se derrota uno de los principales beneficios de Elektra: "El administrador / usuario decide el formato de configuración, no el desarrollador de la aplicación".

Nunca fue posible que un complemento de almacenamiento pueda usarse para cualquier aplicación. Esto no significa que retiremos el poder de administrador / usuario para cambiar los puntos de montaje. Pero debemos ser honestos y hacer una gran exención de responsabilidad de que hacerlo implica algunos riesgos.

Esa nunca fue mi sugerencia. Por supuesto, deberíamos aceptar todos los JSON válidos. La pregunta es qué KeySet producimos. Si usamos "@value" para valores que no son hojas, como se sugirió anteriormente, aún podríamos aceptar todos los JSON válidos. El KeySet resultante tendría una estructura ligeramente diferente en algunas ocasiones.

En este problema ya hemos perdido muchísimas horas en unos 10 años, sin ningún progreso. La primera idea fue keytometa, luego directoryvalue, con muchos pasos intermedios. ¿Por qué no aceptar JSON como es? Funcionará para la mayoría de las aplicaciones. ¿Vale la pena una estructura ligeramente mejor?

El punto es que las aplicaciones encuentran formas de evitar las limitaciones.

Las aplicaciones incluso encuentran formas de evitar la ausencia de una biblioteca de configuración. ¿Por qué usarían una biblioteca de configuración que les da limitaciones que actualmente no tienen? Es bastante trivial implementar un archivo de propiedades que permita cualquier nombre de clave con cualquier valor. ¿Para qué sería útil Elektra si ni siquiera ofrece esto?

Y en nuestro caso incluso podemos ayudarles con bibliotecas.

Primero, debemos aclarar los objetivos antes de realizar soluciones complejas.

No estoy de acuerdo. Los complementos de almacenamiento ya son extremadamente complejos,

¿Miraste simpleini, ni, c o mini? Aún puede escribir fácilmente un complemento de almacenamiento útil en menos de un día.

relativamente hablando, esto solo sería un inconveniente menor. (asumiendo que proporcionamos una buena biblioteca de almacenamiento con funciones auxiliares)

Desafortunadamente, la suposición no se sostiene. También intentamos crear bibliotecas auxiliares desde hace muchos años, con muy poco éxito. Lo que se hace en el núcleo correctamente siempre fue la mejor solución.

Tanto los documentos CDATA como HERE necesitan reservar algo de sintaxis, desde el punto de vista actual de Elektra no hay diferencia. Ambas versiones son una restricción en los nombres de las claves.

No, los documentos de HERE no reservan ninguna sintaxis. Puede decidir sobre la marcha (por ejemplo, en función de los datos) qué palabra clave desea utilizar para marcar el final del documento.

Creo que deberíamos olvidarnos de estas características y utilizar correctamente los metadatos para dar semántica a las claves.
Acaba de decir que algunos complementos de almacenamiento podrían no admitir metadatos. Entonces parece que esta no es una opción.

La forma correcta es especificar claves en el espacio spec nombres

Por supuesto, si cambia de opinión y dice que un formato de almacenamiento puede limitar las capacidades de Elektra, el problema desaparece. Pero eso cambia fundamentalmente la promesa de Elektra a los usuarios. Limitaríamos a todos los usuarios solo para permitir que algún desarrollador guarde algunas líneas de código relacionadas con la codificación de valores especiales.

Separé esta pregunta al # 3515

Sí, el nombre de la clave puede tener restricciones.
Por favor decídete. Todo este tiempo ha argumentado que no puede haber restricciones.

Los nombres clave, también conocidos como keySetName pueden tener restricciones (es decir, fallar en algunos argumentos), los nombres de las partes clave, también conocidos como keySetBaseName , no pueden tener restricciones (nunca fallan en ningún argumento). No soy fanático ni dogmático, podemos discutir esto y todo lo demás si ves un problema fundamental con nuestras metas más importantes.

Podemos hacer cumplir la restricción del sistema: / elektra.
Podríamos requerir una bandera en keyNew para permitir tales nombres. De lo contrario, una aplicación que acepte nombres de claves del usuario tendría que desinfectar la entrada.

Estaba pensando en un complemento que rechaza todo lo escrito en /elektra que no confirme qué herramientas pueden escribir allí. Sin embargo, creo que es de baja prioridad.

No, los documentos de HERE no reservan ninguna sintaxis. Puede decidir sobre la marcha (por ejemplo, en función de los datos) qué palabra clave desea utilizar para marcar el final del documento.

Sí, lo hacen << todavía está reservado para comenzar con los documentos AQUÍ. El marcador de finalización lo define el usuario, pero el inicio, obviamente, no puede serlo.
De todos modos, esto no es importante.

Nunca fue posible que un complemento de almacenamiento pueda usarse para cualquier aplicación.

Para mí está bien, si no todos los complementos son compatibles con todo, pero si una aplicación usa un complemento de almacenamiento personalizado, el administrador / usuario no tiene otra opción. Debería haber al menos alguna opción, incluso si es solo, por ejemplo, YAML o TOML. Si solo un formato personalizado adaptado a Elektra lo admite todo, me temo que nadie usará Elektra. Para mí, una de las características más importantes de Elektra es que un usuario / amdin siempre puede usar su formato de configuración favorito sin importar la aplicación.

¿Miraste simpleini, ni, c o mini? Aún puede escribir fácilmente un complemento de almacenamiento útil en menos de un día.

c es de solo escritura. mini no admite metadatos y AFAICT elimina todos los comentarios de un archivo. simpleini tampoco admite metadatos y enumera muchas más restricciones en el archivo README.

En general, los complementos INI no son un buen ejemplo, porque INI realmente no tiene una especificación, por lo que no hay limitaciones provenientes del formato.

ni se basa en una biblioteca existente. Por eso el código es bastante corto y sencillo.

Pero ni es en realidad un muy buen ejemplo de lo que me gustaría hacer. Utiliza una interpretación muy específica de los archivos INI que pueden no ser deseados por los desarrolladores de aplicaciones. En realidad, esto plantea otra pregunta.

¿Cuál es el caso de uso más importante?

1. Convertir una aplicación existente a Elektra y mantener los mismos archivos de configuración
2. Escribir nuevas aplicaciones cuyo formato de configuración se basará en lo que mejor se adapte a Elektra

Para el primer caso, necesitamos complementos que puedan leer cualquier archivo y producir KeySet s útiles.
Para el segundo caso, incluso las restricciones severas como las impuestas por ni pueden no ser un problema.

La forma correcta es especificar claves en el espacio spec nombres

Sí, esta es una posible solución. Pero requiere mucho trabajo para que spec funcione correctamente. Como mínimo, necesitamos algunas garantías de pedido de complementos dentro de la postgetstorage .

Pero causa algunas dificultades con los metadatos inferidos del formato de almacenamiento (por ejemplo, tipo, matriz). ¿Sería un error si leemos una matriz JSON que no tiene metadatos array coincidentes en spec ?

Sin embargo, esto no resuelve el problema de las claves que no son hojas con valores.

Los nombres clave, también conocidos como keySetName pueden tener restricciones (es decir, fallar en algunos argumentos), los nombres de las partes clave, también conocidos como keySetBaseName , no pueden tener restricciones (nunca fallan en ningún argumento).

Estas son dos cosas completamente diferentes. keySetName acepta un nombre de clave con escape , mientras que keySetBaseName acepta una parte de un nombre de clave sin escape . Por supuesto, un nombre de clave de escape tiene restricciones.

Sin embargo, todo lo que rodea a los nombres de clave de Elektra se basa en una _ parte de nombre de clave_ (ver también el documento en # 3447). Entonces, la única pregunta que debemos discutir es:

_¿Qué es una parte de nombre clave? _

Para mí está bien, si no todos los complementos son compatibles con todo, pero si una aplicación usa un complemento de almacenamiento personalizado, el administrador / usuario no tiene otra opción.

No veo cómo esto sería posible. En Elektra siempre puede implementar alternativas siempre que esta alternativa produzca KeySets adecuados para la aplicación. Lo único arreglado es el KeySet, pero la forma en que se produce el KeySet es siempre algo intercambiable. Para mí, este es el principal beneficio de Elektra.

Es por eso que el KeySet (incluidos los nombres de las claves) son las decisiones más importantes (y más difíciles) de todas.

Debería haber al menos alguna opción, incluso si es solo, por ejemplo, YAML o TOML. Si solo un formato personalizado adaptado a Elektra lo admite todo, me temo que nadie usará Elektra. Para mí, una de las características más importantes de Elektra es que un usuario / amdin siempre puede usar su formato de configuración favorito sin importar la aplicación.

No veo cómo ninguna de las decisiones de las que estamos hablando afecte la posibilidad. Si se esfuerza lo suficiente en un complemento de almacenamiento para su formato de configuración favorito (incluidas las extensiones sintácticas o similar), podrá ejecutar cualquier aplicación.

mini no admite metadatos y AFAICT elimina todos los comentarios de un archivo. simpleini tampoco admite metadatos y enumera muchas más restricciones en el archivo README.

Para la mayoría de las aplicaciones, estas restricciones son irrelevantes. Una herramienta que utilizo funciona con simpleini y también con mini como backends.

Creo que ya llegamos casi a la misma conclusión: que sea lo que sea que suceda para producir el KeySet correcto, debe suceder dentro del complemento de almacenamiento. El uso de una "biblioteca de almacenamiento" es por supuesto ventajoso, pero al final es un detalle de implementación. La idea de que "los complementos posteriores corrigen lo que el complemento de almacenamiento hizo mal" falló. Entonces, ¿por qué necesitamos más sintaxis en el nombre de la clave? Cualquier sintaxis necesaria se puede eliminar dentro del complemento de almacenamiento.

1. Convertir una aplicación existente a Elektra y mantener los mismos archivos de configuración
2. Escribir nuevas aplicaciones cuyo formato de configuración se basará en lo que mejor se adapte a Elektra

Imho "1". es más importante ahora, ya que lo necesitamos para KDE. Entonces, de alguna manera, necesitamos a Elektra en una forma que no destruya el complemento kconfig .

Sobre 2." No sé qué significa "se adapta mejor a Elektra". Elektra no tiene ningún propósito en sí mismo, su único propósito es satisfacer las necesidades de desarrolladores, usuarios y administradores.

Pero causa algunas dificultades con los metadatos inferidos del formato de almacenamiento (por ejemplo, tipo, matriz). ¿Sería un error si leemos una matriz JSON que no tiene metadatos de matriz coincidentes en la especificación?

No, solo lo contrario es un error: si la especificación requiere una matriz pero no hay ninguna.

Sí, esta es una posible solución. Pero requiere mucho trabajo para que las especificaciones funcionen correctamente. Como mínimo, necesitamos algunas garantías de pedido de complementos dentro de la posición de almacenamiento posterior.

Sí, estoy totalmente de acuerdo. Y es necesario hacer algo con spec todos modos, no podemos dejarlo como está.

Sin embargo, esto no resuelve el problema de las claves que no son hojas con valores.

Usted argumentó que esto no es importante de todos modos: stick_out_tongue_winking_eye:

Y estoy de acuerdo, para casi todas las aplicaciones no será importante.

¿Qué es una parte de nombre clave?

¿Puede hacer un problema que enumere los puntos abiertos / no claros? O mejor aún: ¿agregarlo al # 3514?

Para mí está bien, si no todos los complementos son compatibles con todo, pero si una aplicación usa un complemento de almacenamiento personalizado, el administrador / usuario no tiene otra opción.

No veo cómo esto sería posible. En Elektra siempre puede implementar alternativas siempre que esta alternativa produzca KeySets adecuados para la aplicación. Lo único arreglado es el KeySet, pero la forma en que se produce el KeySet es siempre algo intercambiable. Para mí, este es el principal beneficio de Elektra.

Es por eso que el KeySet (incluidos los nombres de las claves) son las decisiones más importantes (y más difíciles) de todas.

Debería haber al menos alguna opción, incluso si es solo, por ejemplo, YAML o TOML. Si solo un formato personalizado adaptado a Elektra lo admite todo, me temo que nadie usará Elektra. Para mí, una de las características más importantes de Elektra es que un usuario / amdin siempre puede usar su formato de configuración favorito sin importar la aplicación.

No veo cómo ninguna de las decisiones de las que estamos hablando afecte la posibilidad. Si se esfuerza lo suficiente en un complemento de almacenamiento para su formato de configuración favorito (incluidas las extensiones sintácticas o similar), podrá ejecutar cualquier aplicación.

>

Debería haber agregado más contexto a mi respuesta. Creo que estamos en la página en este sentido. Mi comentario fue en respuesta a esta declaración suya:

Creo que la mayoría de las aplicaciones no serán muy exigentes de todos modos (por ejemplo, solo tienen valores hoja y no necesitan metadatos excepto el tipo), por lo que todo lo que discutimos aquí solo es relevante para aplicaciones excepcionales. Para estas aplicaciones, creo que es mejor que los desarrolladores de aplicaciones desarrollen sus propios complementos de almacenamiento o utilicen nuestros mejores complementos de almacenamiento, que admiten este tipo de cosas.

En particular, la parte: "Creo que es mejor que los desarrolladores de aplicaciones desarrollen sus propios complementos de almacenamiento".

Si bien esto siempre será una opción, creo que _ nunca_ debería ser algo que recomendamos o incluso sugerir como solución. El uso de un complemento de almacenamiento personalizado no estaría en línea con la filosofía de Elektra y debería evitarse en la medida de lo posible. Nota: por "complemento de almacenamiento personalizado" me refiero a un complemento que está diseñado para funcionar con una aplicación específica, pero que no garantiza que sea compatible con el resto de Elektra. Estaría totalmente bien, si alguien quiere usar un formato personalizado y desarrolla un complemento correspondiente que sea compatible con el entorno estándar de Elektra.

Creo que ya llegamos casi a la misma conclusión: que sea lo que sea que suceda para producir el KeySet correcto, debe suceder dentro del complemento de almacenamiento. El uso de una "biblioteca de almacenamiento" es por supuesto ventajoso, pero al final es un detalle de implementación. La idea de que "los complementos posteriores corrigen lo que el complemento de almacenamiento hizo mal" falló.

Sí, básicamente es eso. El complemento de almacenamiento no puede depender de otros complementos (excepto tal vez valores binarios y cosas por el estilo).

Aunque tal vez un complemento sea en realidad la solución después de todo. Tendré que pensarlo más y publicaré la idea, si creo que funciona.

Pero causa algunas dificultades con los metadatos inferidos del formato de almacenamiento (por ejemplo, tipo, matriz). ¿Sería un error si leemos una matriz JSON que no tiene metadatos de matriz coincidentes en la especificación?

No, solo lo contrario es un error: si la especificación requiere una matriz pero no hay ninguna.

Vayamos un paso más allá. ¿Qué pasa si tenemos este JSON [ "a", "b" ] sin especificación y lo exportamos a un formato sin metadatos y sin matrices (por ejemplo, mini )? La información de que se trata de una matriz se perderá.

Como este es un caso marginal, podríamos decir simplemente: Esto es lamentable, pero es lo que es.

Y estoy de acuerdo, para casi todas las aplicaciones no será importante.

Lo mismo se puede decir sobre el uso de nombres de clave arbitrarios. Casi todas las aplicaciones no tendrían problemas si no pueden usar /@elektra/ en sus nombres de clave.

¿Puede hacer un problema que enumere los puntos abiertos / no claros? O mejor aún: ¿agregarlo al # 3514?

Haré una lista en alguna parte, para que podamos discutirlo el lunes.

Estaría totalmente bien, si alguien quiere usar un formato personalizado y desarrolla un complemento correspondiente que sea compatible con el entorno estándar de Elektra.

De hecho, estaba pensando en estas líneas. Pero sí, las particularidades aparecen fácilmente. Por ejemplo, el complemento kconfig los metadatos solo pueden tener un solo carácter, por lo que obviamente no serán muy compatibles con nuestros metadatos (al menos siempre que el analizador no reasigne este carácter al significado real, que por el momento no ocurre). Por el momento, simplemente pasamos los metadatos de un solo carácter a través de nuestra capa y, si es necesario, hacemos en la biblioteca kconfig lo que hubiera sucedido si hubiera analizado directamente el archivo.

@mpranj , ¿ya verificaste si esto realmente funciona? Al menos [$e] parece existir con bastante frecuencia.

Aunque tal vez un complemento sea en realidad la solución después de todo. Tendré que pensarlo más y publicaré la idea, si creo que funciona.

Por el momento, preferiría que arreglemos las cosas donde ya sabemos cómo arreglarlas.

Como este es un caso marginal, podríamos decir simplemente: Esto es lamentable, pero es lo que es.

Exactamente, si desea la "función X", no puede tener un complemento sin esta función en la cadena de importación / exportación. Lo mismo con los comentarios y así sucesivamente.

claves no hoja con valores.
Lo mismo se puede decir sobre el uso de nombres de clave arbitrarios. Casi todas las aplicaciones no tendrían problemas si no pueden usar / @ elektra / en sus nombres de clave.

Si. Pero también hay una gran diferencia entre algo que no funciona con algunos complementos y algo que nunca funcionará con Elektra.

Haré una lista en alguna parte, para que podamos discutirlo el lunes.

: +1:

Pero también hay una gran diferencia entre algo que no funciona con algunos complementos y algo que nunca funcionará con Elektra.

Entiendo su punto, pero de manera realista, ¿con qué frecuencia no tener claves /@elektra/ realmente será un problema?

Aunque tal vez un complemento sea en realidad la solución después de todo. Tendré que pensarlo más y publicaré la idea, si creo que funciona.

Por el momento, preferiría que arreglemos las cosas donde ya sabemos cómo arreglarlas.

La idea era un complemento que siempre está montado y codifica / decodifica los nombres de las claves. Entonces, un complemento de almacenamiento solo tiene que lidiar con KeySet s que, por ejemplo, no contienen claves /@elektra/ . Pero debido a la codificación, la aplicación aún puede usar cualquier nombre de clave. El complemento de almacenamiento puede usar claves /@elektra/ para su propio propósito, por ejemplo, metadatos y valores que no son hojas.

El efecto sería una pequeña limitación en los archivos de almacenamiento, pero no en las aplicaciones. La complejidad de los complementos de almacenamiento tampoco se vería afectada, porque el complemento de almacenamiento no tiene que usar ninguna clave /@elektra/ . Solo aquellos complementos que quieran admitir, por ejemplo, metadatos, deben escribir código adicional, pero ese es siempre el caso.

Entiendo tu punto, pero siendo realistas, ¿con qué frecuencia no tener claves / @ elektra / será un problema?

Probablemente no haya ningún problema. Pero será un problema tanto ahora como más adelante. Entonces, ¿por qué reservarlo ahora y no cuando realmente encontramos un caso de uso donde se necesita algo como esto? Entonces sabemos que no es solo una fantasía y podemos elegir un nombre apropiado.

En los lenguajes de programación, (normalmente) solo reservamos palabras clave cuando en realidad hacemos extensiones sintácticas.

por ejemplo, metadatos

Para los metadatos de las claves, spec es la mejor solución, ya que se refiere a todos los espacios de nombres. Los metadatos no especificados son básicamente solo conservación de formato útil y similar.

porque el complemento de almacenamiento no tiene que usar ninguna tecla / @ elektra /

No es que un complemento de almacenamiento use cualquier nombre, la pregunta es el comportamiento si encuentra <strong i="14">@elektra</strong> = something en un archivo.

Entonces, ¿por qué reservarlo ahora y no cuando realmente encontramos un caso de uso donde se necesita algo como esto?

Porque este es un gran cambio radical y antes de la 1.0 es el momento adecuado para hacer esas cosas. Sobre todo porque ya están cambiando los nombres de las claves.

También hay un caso de uso muy real en este momento. Como mínimo, permite almacenar claves no hoja con valores en cualquier formato.

Para los metadatos de las claves, spec es la mejor solución, ya que se refiere a todos los espacios de nombres.

Solo mencionaré array . Piense un poco en el tema # 3514 y luego dígame cómo almacenar correctamente una matriz en un archivo de propiedades de Java.

Sería bueno, si los metadatos solo estuvieran almacenados en spec:/ (eso también resolvería algún problema con el complemento spec ), pero requeriría algunos cambios muy grandes en Elektra para que funcione bien.

la pregunta es el comportamiento si encuentra <strong i="17">@elektra</strong> = something en un archivo

Si el complemento usa @elektra para codificar algo (por ejemplo, valores que no son hojas), eso es lo que sucede.
De lo contrario: "ERROR: nombre de clave ilegal"

Haré una lista en alguna parte, para que podamos discutirlo el lunes.

Como se prometió en https://github.com/ElektraInitiative/libelektra/issues/3223#issuecomment -709389141, ahora agregué # 3517.

dime cómo almacenar correctamente una matriz en un archivo de propiedades de Java.

Solo funciona con spec .

pero requeriría algunos cambios muy importantes en Elektra para que funcione bien.

¿Se necesitan algunos cambios que aún no están en el rastreador de problemas? Creo que es imprescindible para 1.0 que al menos los conceptos básicos de las especificaciones funcionen bien (y para deshacerse de las cosas que no funcionan).

Solo funciona con spec .

¿Pero cómo? Necesita los metadatos array en los otros espacios de nombres para saber qué tan grande es realmente la matriz.

¿Se necesitan algunos cambios que aún no están en el rastreador de problemas? Creo que es imprescindible para 1.0 que al menos los conceptos básicos de las especificaciones funcionen bien (y para deshacerse de las cosas que no funcionan).

Es imposible decirlo. Necesitamos decidir qué especificaciones deberían hacer realmente. Entonces tenemos que averiguar si es posible y cómo. Incluso entonces, es muy probable que encontremos algunos casos extremos que no funcionen. Elektra es tan complicado que es casi imposible una razón y una buena cobertura de pruebas es al menos tan difícil. Gran parte de Elektra todavía se basa en principios vagamente o nada definidos.

El mayor problema son definitivamente las posiciones actuales de los complementos. Pero eso requerirá mucho trabajo para solucionarlo. En mi opinión, esa parte esencialmente necesita un rediseño completo.

¿Pero cómo? Necesita los metadatos de la matriz en los otros espacios de nombres para saber qué tan grande es realmente la matriz.

Sí, la especificación realmente necesitaría comprender la semántica de los metadatos, como las matrices. Por lo tanto, verificaría todos los espacios de nombres cómo se ve realmente la matriz y luego agregaría los metadatos adecuados array .

Elektra es tan complicado que es casi imposible una razón y una buena cobertura de pruebas es al menos tan difícil.

Estoy de acuerdo, así que deja que sea más simple. Ahora es la oportunidad perfecta. Aprendimos mucho sobre lo que no se puede hacer. Así que vamos a deshacernos de esas cosas.

El mayor problema son definitivamente las posiciones actuales de los complementos. Pero eso requerirá mucho trabajo para solucionarlo. En mi opinión, esa parte esencialmente necesita un rediseño completo.

Estoy cada vez más de acuerdo con @mpranj en que los ganchos para complementos globales específicos no son una mala idea. Los requisitos para dichos complementos son bastante complicados y, por lo tanto, el posicionamiento genérico se volvería demasiado complicado.

Así que simplemente no tendríamos posiciones de complementos globales genéricos, sino solo posiciones específicas para mmap, especificaciones y notificaciones (las únicas que realmente necesitamos para 1.0). Las posiciones genéricas estarían bien, pero claramente está más allá de nuestra capacidad para probar esto. Modifiqué la decisión en 89b29034e1d505f36d298f01bf0fcfd13aa1af70

Más discusiones por favor en # 3514