Libelektra: Biblioteca para tipos

Creo que debería ser la forma excepcional de formar bibliotecas a partir de propuestas. Tiene mucho más sentido extraer una funcionalidad común entre complementos y hacer una biblioteca a partir de eso. El complemento TOML de @ bauhaus93 tiene toneladas de código que tendría mucho sentido para colocarse en una biblioteca (por ejemplo, el código de manejo de comentarios).

No me malinterpretes, es una buena entrada para @ bauhaus93. Y si hay un segundo complemento que necesita la misma funcionalidad, definitivamente deberíamos ponerlo en una biblioteca. Pero crear bibliotecas requiere mucho más esfuerzo que tener un código específico de un complemento y el esfuerzo solo debe realizarse si en realidad hay al menos dos clientes.

@ bauhaus93 si no ve un beneficio inmediato en tener una biblioteca de tipos (por ejemplo, reutilizar con otro complemento), cierre el problema.

si hay un segundo complemento que necesita la misma funcionalidad, definitivamente deberíamos ponerlo en una biblioteca

Siempre que el desarrollador del segundo complemento sepa dónde encontrar el primer complemento y cómo extraer el código de allí sin romper todo, esa es una buena estrategia, sí. Lamentablemente, este no suele ser el caso. Especialmente, dado que a menudo el primer complemento debe cambiarse ampliamente para que pueda usar una biblioteca.

Además, tener la biblioteca podría alentar a alguien a escribir un nuevo complemento de almacenamiento, ya que parte del trabajo ya está hecho.

Pero etiqueté esto como low priority , exactamente porque sabía que es mucho trabajo y probablemente no hay nadie que quiera hacerlo.

Para los tipos, no estoy seguro acerca de la reutilización, excepto quizás por la validación / conversión de enteros no decimales (binario / octal / hexadecimal) o de fecha y hora (TOML usa RFC 3339 de fecha y hora).
Sin relación con los tipos, veo cierta reutilización en la preparación de KeySets por escribir (por ejemplo, funciones que actualizan / agregan array metakeys, eliminan array metakeys de matrices inválidas o faltan comment/#X completo

Es posible que no lo hayas notado todavía, pero también puede haber problemas con la normalización de los valores booleanos que hace el complemento de tipo. Este es probablemente el código más reutilizado, ya que la mayoría de los formatos usarán true / false pero Elektra usa 1 / 0 . Creo que yamlcpp tuvo que agregar un código especial, para que los valores booleanos no se conviertan en números enteros o viceversa (o algo por el estilo).

Ah, sí, me olvidé de eso, el complemento TOML también tiene que normalizar estos valores.

El problema no es solo que hay que normalizar los valores. También tiene que saber exactamente lo que el type plugin no, ya que se ejecuta antes de que el toml Plugin en el kdbSet fase. No estoy seguro, si alguna vez lo implementamos, pero también debe asegurarse de que el complemento type solo produzca 1 / 0 o true / false en la fase kdbSet , independientemente de la configuración proporcionada por el usuario. De lo contrario, toml tendría que poder analizar la configuración del complemento type , ya que el usuario puede establecer valores personalizados verdaderos y falsos (consulte el caso de prueba a continuación)

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

La parte interesante es:

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

El complemento type recibe un 1 en kdbGet (podría ser de toml ), pero devuelve un t en kdbSet . Esto podría llegar tan lejos como para que un usuario defina que true = 0 y false = 1 confundiría totalmente el complemento toml . (Creo que todos los valores booleanos se activarían cada kdbSet )

Esta interacción enormemente compleja es la razón por la que creo que el complemento type debería ser para formatos de almacenamiento que no tienen tipos y aquellos que los tienen deberían prohibir explícitamente el uso de type . Pero para que eso sea factible, necesitamos una manera fácil de admitir tipos dentro de los complementos de almacenamiento, es decir, una biblioteca de tipos.

Dado que el complemento toml también maneja números hexadecimales, probablemente también debería prohibir explícitamente el uso del complemento hexnumber . (aunque en ese caso creo que hay menos posibilidades de problemas)

Además, tener la biblioteca podría alentar a alguien a escribir un nuevo complemento de almacenamiento, ya que parte del trabajo ya está hecho.

La mayoría de los usuarios probablemente solo quieran escribir la gramática y el resto debería suceder mágicamente por sí solo. Me pregunto hasta qué punto el complemento TOML de @ bauhaus93 logró este objetivo. Sería interesante crear un complemento que no sea TOML con el código base del complemento TOML. Sin embargo, una biblioteca de tipos por sí sola me parece demasiado especializada para ser demasiado útil para la gran tarea de "escribir un complemento de almacenamiento".

Para los tipos, no estoy seguro acerca de la reutilización, excepto quizás por la validación / conversión de enteros no decimales (binario / octal / hexadecimal) o de fecha y hora (TOML usa RFC 3339 de fecha y hora).

La fecha / hora existía en Elektra solo para la validación, pero solo se admitía RFC2822. El complemento de fecha podría reutilizar su analizador para validar RFC 3339, pero consideraría esto como una prioridad muy baja.

Lo que sería un poco más emocionante es algo como keyGetDateTime(Key *k, struct tm *tm) de una clave con una fecha (TOML).

Sin relación con los tipos, veo cierta reutilización en la preparación de KeySets a escribir (por ejemplo, funciones que actualizan / agregan metaclaves de matriz, eliminan metaclaves de matriz de matrices no válidas o completan comentarios faltantes / datos de metaclaves # X).

Sí, eso podría ser interesante. Pero aún más fascinante sería la posibilidad de modificar directamente la gramática y el código táctil lo menos posible: guiño:

Es posible que no lo hayas notado todavía, pero también puede haber problemas con la normalización de los valores booleanos que hace el complemento de tipo.

Lo que falta es un tutorial / explicación en doc / tutorials / storage-plugins.md que brinda una vista actualizada de los complementos en los que un complemento de almacenamiento debería confiar. # 2330 mostrará si se puede necesitar "binario" y si sigue siendo adecuado como almacenamiento predeterminado.

También debe saber exactamente qué hace el tipo de complemento, ya que se ejecuta antes que el complemento toml en la fase kdbSet.

Probablemente, los complementos de almacenamiento deberían dejar de usar el complemento de tipo y simplemente hacer su normalización ellos mismos (desde lo que sea verdadero / falso en su formato hasta 1/0 en Elektra y así sucesivamente). @ bauhaus93 ¿ qué otra funcionalidad del tipo de complemento usas?

Esto podría llegar tan lejos como para que un usuario defina que verdadero = 0 y falso = 1, lo que confundiría totalmente al complemento toml.

Yo estaría a favor de reducir la funcionalidad del tipo de complemento. En todo caso, el usuario debe definir algunos valores verdaderos / falsos adicionales (que obviamente no eran valores verdaderos / falsos antes).

Dado que el complemento toml también maneja números hexadecimales, probablemente también debería prohibir explícitamente el uso del complemento hexnumber. (aunque en ese caso creo que hay menos posibilidades de problemas)

No hay forma de expresar que los complementos no funcionan juntos (Tener tal funcionalidad haría el montaje mucho más complicado. También sería demasiado trabajo para nosotros mantener una tabla de qué complemento funciona con qué complemento). Pero probablemente nadie tendrá la idea de usarlos juntos, ya que el complemento TOML ya tiene esta funcionalidad y más (por ejemplo, también números binarios).

La mayoría de los usuarios probablemente solo quieran escribir la gramática y el resto debería suceder mágicamente por sí solo.

Eso parece demasiado mágico para ser posible. Podría ser posible con un generador de código personalizado basado en una gramática modificada de Yacc o ANTLR. Pero no creo que haya una manera de tener un código que cree KeySet s simplemente a partir de una gramática para formatos muy diferentes como JSON, XML, TOML y edn . Como descubrió @ 'sanssecours, también existen formatos como YAML que son muy difíciles de expresar en un formato gramatical estándar.

Sin embargo, una biblioteca de tipos por sí sola me parece demasiado especializada para ser demasiado útil para la gran tarea de "escribir un complemento de almacenamiento".

Por supuesto, podríamos extender la biblioteca a una biblioteca general storage que proporcione más funciones auxiliares para complementos de almacenamiento (por ejemplo, tratar con stdin / stdout y tuberías para importación / exportación). El tipo de material sería entonces parte de eso.

También creo que subestimas lo complicado que puede ser el tipo de letra. Si tuviéramos una biblioteca de tipos estándar, extender el sistema de tipos también sería más fácil, por ejemplo, almacenar versiones binarias previamente analizadas de enteros además (a las versiones de cadena para reducir la sobrecarga de análisis). Una biblioteca storage también podría usar API internas (si es necesario), ya que es mantenida por los desarrolladores de Elektra.

Otra, una biblioteca de tipos estándar también garantizaría mensajes de error estándar para problemas de tipos. De modo que incluso habría una ventaja para los usuarios finales.

Lo que sería un poco más emocionante es algo como keyGetDateTime (Key * k, struct tm * tm)

Parece un trabajo para la parte de conversión de libease (como elektraKeyToDateTime (const Key * key, struct tm * dateTime) ).

@ bauhaus93 las funciones allí podrían ser útiles para toml también. Están diseñados de tal manera que, por ejemplo, elektraKeyToFloat y elektraFloatToString perfectos y sin pérdidas de ida y vuelta (no importa si comienzas con una cadena flotante) y también se usan en la API de alto nivel. Entonces, si toml crea la clave con elektra*ToString , definitivamente puede ser leída correctamente por la API de alto nivel y toml definitivamente puede leer correctamente cualquier API de highlevel producida con elektraKeyTo* .

una vista actualizada de los complementos en los que debe confiar un complemento de almacenamiento.

En mi opinión, un complemento de almacenamiento nunca debería _rectamente_ en ningún otro complemento. Los complementos de almacenamiento se pueden mejorar con otros complementos, pero lo ideal es que funcionen de forma independiente.

Incluso al tratar con claves binarias, se resolvería mejor con una biblioteca de tipo / almacenamiento. Nuevamente, garantiza algún estándar básico para mensajes de error, etc. También evita el uso del complemento binary para formatos que no lo necesitan. Si bien binary combinado con, por ejemplo, quickdump funcionaría, es malo tanto para la velocidad como para el tamaño de almacenamiento.

Probablemente, los complementos de almacenamiento deberían dejar de usar el complemento de tipo y simplemente hacer su normalización simplemente ellos mismos

Por eso propuse una biblioteca. Es mucho mejor proporcionar una biblioteca que haga el trabajo que simplemente dar una descripción informal (o incluso una especificación formal) de lo que tiene que hacer el complemento. Especialmente, si la especificación puede cambiar con el tiempo.

Yo estaría a favor de reducir la funcionalidad del tipo de complemento.

¿Por qué quitar la funcionalidad que ya está implementada? Originalmente, la idea era tener un complemento boolean separado, pero eso también causaba problemas, debido al pedido de complementos y cosas por el estilo.

En todo caso, el usuario debe definir algunos valores verdaderos / falsos adicionales (que obviamente no eran valores verdaderos / falsos antes).

Realmente no hay necesidad de eso. Solo hay un problema si más de un complemento define qué es un valor booleano.

Incluso true = 0 y false = 1 están totalmente bien. La propia Elektra multa a los booleanos como " 1 es el único valor verdadero y 0 es el único valor falso".

No hay forma de expresar que los complementos no funcionan juntos (Tener tal funcionalidad haría el montaje mucho más complicado. También sería demasiado trabajo para nosotros mantener una tabla de qué complemento funciona con qué complemento).

Estoy en desacuerdo. Por supuesto, una lista exhaustiva sería imposible (después de todo, también hay complementos de terceros), pero la solución es simple. Deje que los complementos hagan la verificación por sí mismos. Ya sea en elektra<Plugin>Get o en otra función que se llame durante kdb mount .

Además de booleano, el complemento TOML también establece los tipos string, double y (unsigned_) long_long en la lectura.

Estoy de acuerdo con @kodebach , en que el type solo debe ser utilizado por complementos sin un sistema de tipos incorporado, debido a dificultades en la interacción.
P.ej. el complemento TOML establece la metakey type para enteros en lectura también en valores no decimales (mientras lo convierte a decimal, almacena la representación no decimal en origvalue ). Sin embargo, si desea cambiar un valor escrito con kdb set (y hacerlo mediante un valor binario / octal / hexadecimal), no puede hacerlo directamente (configurando el valor de la clave), porque el type Las comprobaciones del tipo de complemento origvalue su lugar. (Eliminar la metaclave type antes de establecer un nuevo valor no funcionaría, ya que la metaclave se restablecerá en la lectura).

El problema no es solo que hay que normalizar los valores. También debe saber exactamente qué hace el tipo de complemento, ya que se ejecuta antes que el complemento toml en la fase kdbSet. No estoy seguro, si alguna vez lo implementamos, pero también debe asegurarse de que el complemento de tipo solo produzca 1/0 o verdadero / falso en la fase kdbSet, independientemente de la configuración proporcionada por el usuario. De lo contrario, toml tendría que poder analizar la configuración del complemento de tipo, ya que el usuario puede establecer valores personalizados verdaderos y falsos (consulte el caso de prueba a continuación)

Sí, ya me preguntaba si / cómo puedo verificar los valores booleanos definidos por el usuario. Actualmente, al escribir, el complemento TOML solo considera valores de "1" y "true" como verdaderos, el resto se vería como falso.

@kodebach escribió:

Eso parece demasiado mágico para ser posible.

Con Augeas es posible (pero los árboles que obtienes no son tan deseables). Sería interesante lo lejos que estamos con la solución actual de TOML. Por supuesto, necesita escribir algún código de emisor, pero esto generalmente no es tan dramático.

JSON, XML

La ventaja de Elektra es que se pueden implementar formatos tan diferentes en diferentes tecnologías. Intentar implementar XML desde cero probablemente no sea la mejor idea. Si se pudieran cubrir formatos similares a INI, ya sería asombroso.

Pero, por supuesto, lo primero y más importante es obtener un buen complemento de TOML: 1st_place_medal:

Otra, una biblioteca de tipos estándar también garantizaría mensajes de error estándar para problemas de tipos.

La verificación se puede hacer fácilmente en otros complementos (una vez que se haya realizado el # 2963). Si un complemento solo verifica y falla con un hermoso mensaje de error, hay pocas interacciones o ninguna.

Suena como un trabajo para la parte de conversión de Libease

Sí, probablemente algunas de las cosas de TOML podrían ir a libease o libmeta.

En mi opinión, un complemento de almacenamiento nunca debería depender de ningún otro complemento.

Para el binario, todavía no estoy seguro (ya que probablemente sea algo que no sea necesario para los backends predeterminados), para todas las demás funciones, esta también es mi conclusión. Sin embargo, esta conclusión aún no está ampliamente aceptada (¿@sanssecours?) Ni está documentada.

Por eso propuse una biblioteca. Es mucho mejor proporcionar una biblioteca que haga el trabajo que simplemente dar una descripción informal (o incluso una especificación formal) de lo que tiene que hacer el complemento. Especialmente, si la especificación puede cambiar con el tiempo.

Depende: si hay una gran cantidad de posibilidades válidas, un tutorial / descripción puede ser mejor que una biblioteca complicada que de alguna manera intenta dar esta flexibilidad. Y para las serializaciones existe una inmensa gama de posibilidades válidas y muchas de ellas tienen implementaciones triviales (por ejemplo, simplemente llamar a elektraFormat con algunos parámetros) hasta implementaciones complicadas (por ejemplo, si admiten muchas representaciones de conveniencia).

¿Por qué quitar la funcionalidad que ya está implementada?

Actualmente, Elektra está colapsando por el peso de mantener demasiado código. Cada línea de código inútil (en el sentido de que nadie la usa) que eliminamos hace que Elektra sea mejor.

Desafortunadamente, incluso el código separado en complementos crea problemas: por ejemplo, en el servidor de compilación o una vez que un usuario intenta usarlo, hay interacciones no deseadas / falta de documentación / ...

No podemos publicar todo lo que tenemos actualmente como 1.0, entonces Elektra sería una decepción. Necesitamos deshacernos de todo lo que no es necesario. Agradecemos cada limpieza que pueda hacer.

Esa es también la razón por la que TOML reemplazará a INI. N.º 3491

Deje que los complementos hagan la verificación por sí mismos.

Rara vez era una buena solución. Se vuelve muy inconsistente y el orden de agregar complementos puede producir resultados diferentes. ¿Existe tal código en alguna parte?

@ bauhaus93 escribió:

Además de booleano, el complemento TOML también establece los tipos string, double y (unsigned_) long_long en la lectura.

¿Pero todo lo hace por sí solo sin el complemento de tipo? ¿Para qué se utiliza el tipo de complemento?

En su lugar, tendría que cambiar la metaclave de valor de origen.

Sí, aquí todavía no tenemos una buena solución (# 3056). keySetString elimina el valor original, pero de alguna manera el comportamiento aún no es el esperado por el usuario.

Actualmente, al escribir, el complemento TOML solo considera los valores "1" y "verdadero" como verdaderos, el resto se vería como falso.

Probablemente deberíamos ser más estrictos y fallar en todo lo que no sea "0" o "1". En el archivo TOML en sí, ¿solo permite "verdadero" y "falso" y nada más?

¿Pero todo lo hace por sí solo sin el complemento de tipo? ¿Para qué se utiliza el tipo de complemento?

Sí, lo hace por sí solo, los diferentes tipos se emparejarán durante el lexing. Sin embargo, no verifica si los valores decimales / dobles sobrepasan / subdesbordan long_long / double , así que creo que eso lo hace el complemento type .

Probablemente deberíamos ser más estrictos y fallar en todo lo que no sea "0" o "1". En el archivo TOML en sí, ¿solo permite "verdadero" y "falso" y nada más?

Sí, puedo hacerlo más estricto. En el archivo en sí, solo true o false se escribe / lee como booleano.

para todas las demás funciones, esta es también mi conclusión.

En ese caso, necesitamos una biblioteca type . De lo contrario, cualquier complemento de almacenamiento para un formato con tipos habría vuelto a implementar el tipo de material (ya que depender de otro complemento está fuera de discusión).

si hay una gran cantidad de posibilidades válidas, un tutorial / descripción podría ser mejor

Pero en ese caso, un complemento por separado tampoco es la solución, porque también hay una gran cantidad de posibles interacciones que deben tenerse en cuenta en ambos complementos.

¿Existe tal código en alguna parte?

AFAIK, no, ni siquiera estoy seguro de que un complemento pueda detectar qué otros complementos están montados.

¿Pero todo lo hace por sí solo sin el complemento de tipo? ¿Para qué se utiliza el tipo de complemento?

Sí, lo hace por sí solo, los diferentes tipos se emparejarán durante el lexing. Sin embargo, no verifica si los valores decimales / dobles sobrepasan / subdesbordan long_long / double , así que creo que eso lo hace el complemento type .

Sí, type también verifica el rango, valida float / double y algunas otras cosas como enum s.

Probablemente deberíamos ser más estrictos y fallar en todo lo que no sea "0" o "1". En el archivo TOML en sí, ¿solo permite "verdadero" y "falso" y nada más?

Y ese es exactamente uno de estos casos enormemente complejos y complicados para tipos o, más específicamente, conversión / normalización.

Supongamos que toml solo acepta true / false como entrada y solo produce 0 / 1 en kdbGet y solo acepta 0 / 1 y solo produce true / false en kdbSet . Eso cumpliría tanto con la especificación Elektra como con la especificación TOML para booleanos. Pero un usuario probablemente esperaría que kdb set /some/key/mounted/with/toml true funcionara. Sin embargo, no es así. Con la configuración correcta para type podría funcionar, pero rápidamente se vuelve incómodo. Por ejemplo, ¿y si la clave existiera antes? Entonces no hay type metakey y el complemento type simplemente lo ignora, toml recibe true y se queja de que true no es válido booleano ...

Esto solo muestra que un complemento de almacenamiento DEBE poder manejar todos los tipos que admite el formato de almacenamiento y las conversiones asociadas SIN usar ningún otro complemento.

Actualmente, Elektra está colapsando por el peso de mantener demasiado código. Cada línea de código inútil (en el sentido de que nadie la usa) que eliminamos hace que Elektra sea mejor.

Ese es un punto justo, aunque no creo que simplemente eliminar el código sea la solución correcta. Al menos no cuando se trata de complementos. Dentro del núcleo, estoy de acuerdo, cuanto menos LOC, mejor. Para los complementos, podemos decir fácilmente que el complemento o alguna parte de él es experimental.

En mi opinión, un complemento de almacenamiento nunca debería depender de ningún otro complemento.

Sin embargo, esta conclusión aún no está ampliamente aceptada (¿@sanssecours?) Ni está documentada.

Hasta donde yo sé, no hay ningún lugar en la documentación que indique que un complemento de almacenamiento no debería depender de otros complementos. Tampoco creo que sea bueno desde el punto de vista de la separación de preocupaciones. En mi opinión, escribir un buen complemento de almacenamiento ya es bastante trabajo. Requerir que un complemento de almacenamiento se encargue de la conversión de tipos, claves de directorio y datos binarios (codificación Base64) no facilita ese trabajo.

Tampoco creo que sea bueno desde el punto de vista de la separación de preocupaciones. En mi opinión, escribir un buen complemento de almacenamiento ya es bastante trabajo.

Ese es el objetivo de la biblioteca auxiliar. Divide el código común y, por lo tanto, proporciona (alguna) separación de preocupaciones y facilita el desarrollo del complemento.

Con respecto a la preocupación de elektraTypeGet como biblioteca. Las modificaciones solo son necesarias porque necesitamos reemplazar Plugin * handle con KeySet * config . Si bien es posible que esto no resuelva todos los problemas, al menos permite que el complemento de almacenamiento controle exactamente cómo y cuándo se realiza la escritura.

Como ejemplo, toml podría tener un modo de respaldo INI donde no usa el sistema de tipo TOML sino que difiere a type y un modo TOML normal donde proporciona elektraTypeGet con una configuración muy precisa que garantiza que todo se ajuste a las especificaciones de TOML.

En resumen, una biblioteca es simple y mucho más flexible que un complemento desde el punto de vista del complemento de almacenamiento. Al menos con las posibilidades de configuración de complementos actuales.

Requerir que un complemento de almacenamiento se encargue de la conversión de tipos, claves de directorio y datos binarios (codificación Base64) no facilita ese trabajo.

Analicemos esto:

• Datos binarios: Realmente no hay ningún esfuerzo involucrado en hacer algo como:
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  Un complemento por separado también funcionaría, siempre que el complemento de almacenamiento pueda exigir que el otro complemento esté montado en todas las circunstancias y pueda simplemente asumir que no hay claves binarias. Si el complemento aún tiene que llamar a keyIsBinary y arrojar un error, esta solución no tiene ningún beneficio. Tampoco me gusta que un complemento binario separado tenga que convertir todos los KeySet a la vez, porque entonces todas las claves Base64 desperdician bastante memoria.
• Claves de directorio: en primer lugar, estas claves que no son de hoja con valores son raras en casi todas las circunstancias y deberíamos recomendar que se eviten. Cuando se trata de manejar estas claves, como se indica en el # 3256, creo que una biblioteca es mucho más adecuada para este caso. Hay muchas razones, incluida la sobrecarga de memoria y procesamiento, que complican innecesariamente las configuraciones y la flexibilidad de los puntos de montaje. Parece que @ markus2330 (algo) está de acuerdo conmigo en este punto.
• Tipos: cualquier complemento de almacenamiento para un formato que tenga un sistema de tipos nativo tendrá que hacer al menos algo de trabajo para los tipos. Esto podría ir desde hacer la conversión completa desde cero a través de llamar a alguna biblioteca hasta configurar otro complemento. Nunca será posible que todo funcione. Incluso si tiene una especificación formal muy detallada para los tipos de modo que no se necesite una configuración directa del complemento de tipo, el complemento de almacenamiento tendrá que implementar esta especificación de una forma u otra.

Sin embargo, no comprueba si los valores decimales / dobles sobrepasan / subdesbordan long_long / double, así que creo que eso lo hace el typeplugin.

Ok, entonces básicamente solo lo usas para verificar.

Pero en ese caso, un complemento por separado tampoco es la solución.

No, los complementos separados lamentablemente no son la solución. Fallamos allí. La solución actual es que cada complemento de almacenamiento implementa todo (excepto el manejo binario) basado en doc / tutorials / storage-plugins.md

Pero un usuario probablemente esperaría que kdb set / some / key / installed / con / toml true funcione.

No, un usuario no debería esperar eso. En Elektra 1/0 son verdadero / falso. Solo los complementos de almacenamiento pueden asignar esto a otra cosa.

Justificación: Como al menos en el nivel de especificación solo funciona 1/0, sería confuso hacer funcionar verdadero / falso en cualquier otro lugar (con la excepción de los complementos de almacenamiento).

Esto solo muestra que un complemento de almacenamiento DEBE poder manejar todos los tipos que admite el formato de almacenamiento y las conversiones asociadas SIN usar ningún otro complemento.

Sí estoy de acuerdo.

Ese es un punto justo, aunque no creo que simplemente eliminar el código sea la solución correcta.

Por supuesto, necesitamos eliminar el código "correcto": el que te da expectativas sin cumplirlo o sin introducir problemas con otras partes de Elektra. Y alguna funcionalidad del tipo de complemento parece crear problemas junto con otras partes de Elektra.

Al menos no cuando se trata de complementos. Dentro del núcleo, estoy de acuerdo, cuanto menos LOC, mejor. Para los complementos, podemos decir fácilmente que el complemento o alguna parte de él es experimental.

Desafortunadamente, esto no funciona (todavía *). La gente no juzga el estado de los complementos correctamente, por ejemplo, recientemente vio: # 3472 donde se creía que el complemento INI sin mantenimiento y con errores, y peor aún, el complemento xmltool heredado desalentado, funcionaba perfectamente.

• Podría funcionar mejor si repaso el # 666 y mostramos advertencias durante el montaje.

Requerir que un complemento de almacenamiento se encargue de la conversión de tipos, claves de directorio y datos binarios (codificación Base64) no facilita ese trabajo.

@sanssecours ¿cómo manejan los complementos YAML la conversión de tipo?

Eso es fácticamente incorrecto

Veremos cuando esté hecho: stick_out_tongue_winking_eye:

En resumen, una biblioteca es simple y mucho más flexible que un complemento desde el punto de vista del complemento de almacenamiento. Al menos con las posibilidades de configuración de complementos actuales.

Nadie discutió sobre eso. Pero la flexibilidad a veces tiene un precio enorme.

Realmente no hay ningún esfuerzo involucrado en hacer algo como

base64 no es la única forma de codificar datos binarios. Para los estándares donde se requiere base64, podría estar codificado. ( @sanssecours ¿Es el caso de YAML?)

Sin embargo, para TOML, simplemente dice "Base64 u otra codificación ASCII o UTF-8 adecuada", por lo que se podrían usar otros complementos binarios. Entonces, la solución actual tiene ventajas, ya que los usuarios pueden montar otros complementos binarios según lo deseen o necesiten.

@ bauhaus93 - infos/needs = base64 debe cambiarse a - infos/needs = binary .

Primero, estas claves que no son de hoja con valores son raras en casi todas las circunstancias y deberíamos recomendar que se eviten.

Son muy habituales en muchos formatos. Y pueden ser muy útiles cuando amplía una especifcación (cree subclaves a partir de claves que tenían valores).

[Claves de directorio] Parece que @ markus2330 (algo) está de acuerdo conmigo en este punto.

Estoy de acuerdo en que los complementos de almacenamiento deben manejarlo (tal vez con una biblioteca, pero no con el complemento "directoryvalue", ya que el escape no funciona y el escape correcto es uno de los trabajos principales de un complemento de almacenamiento).

Ok, entonces básicamente solo lo usas para verificar.

No estoy de acuerdo con la frase "el complemento toml usa el complemento type ". En la versión actual, solo recomienda type .

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

Incluso si type se declarara como needs , no lo llamaría "usar". toml realmente no tiene ningún control directo sobre type . Por eso dije que toml basa en type . Espera que type haga ciertas cosas de cierta manera, pero yo no puedo hacer nada, si ese no es el caso.

Podría funcionar mejor si repaso el # 666 y mostramos advertencias durante el montaje.

Estoy de acuerdo. Quizás incluso en cada kdbGet también, a menos que se haya establecido una clave especial "Reconozco que este punto de montaje usa complementos experimentales".

base64 no es la única forma de codificar datos binarios.

Ese es en realidad un argumento para un complemento binary . Aunque todavía me gustaría una interfaz a través de la cual el complemento pueda trabajar con una sola tecla a la vez, esto podría lograr algunos ahorros de memoria y tal vez también ahorros de rendimiento. (Pero ese es otro problema)

Son muy habituales en muchos formatos.

¿Tienes un ejemplo?

Y pueden ser muy útiles cuando amplía una especifcación (cree subclaves a partir de claves que tenían valores).

Es cierto, pero en ese caso recomendaría una solución de "una o la otra" (del punto de vista del usuario final). O usa la clave anterior con el valor único o usa la nueva versión con subclaves. De lo contrario, la configuración probablemente resultará confusa.

Para ser claros, no creo que las claves que no sean de hoja con valores nunca deban usarse, pero deben evitarse si es posible y rara vez (si es que alguna vez) son la solución preferida.

pero no con el complemento "directoryvalue", ya que el escape no funciona

En el # 3256 sugerí el uso de metadatos para resolver problemas de escape. También están mis ideas del # 3223 que resolverían el problema de escape (para cada caso de uso, no solo directoryvalue ), así como algunas otras cosas. Véase también la propuesta (muy formal) . Agregaré explicaciones en un lenguaje sencillo hoy o mañana a ese documento, ya que todavía estoy muy a favor de estos cambios.

@sanssecours ¿cómo manejan los complementos YAML la conversión de tipo?

Yan LR y YAML CPP usan el complemento type para booleanos. YAML CPP también usa el complemento base64 para datos binarios.

base64 no es la única forma de codificar datos binarios. Para los estándares donde se requiere base64, podría estar codificado. ( @sanssecours ¿Es el caso de YAML?)

Sí, hasta donde yo sé, los datos binarios en YAML siempre usan la codificación Base64.

[claves no hoja con valores] ¿Tiene un ejemplo?

XML y la mayoría de los dialectos INI (ya que permiten key=value incluso cuando existe [key] )

Es cierto, pero en ese caso recomendaría una solución de "una o la otra" (del punto de vista del usuario final). O usa la clave anterior con el valor único o usa la nueva versión con subclaves. De lo contrario, la configuración probablemente resultará confusa.

Sí, eso suena razonable. Una vez que sabe que algo es una sección, generalmente mueve el valor a algún lugar dentro de la sección.

Por ejemplo, deluser.conf tiene BACKUP = 0 y BACKUP_TO = "." . Con las secciones, la mayoría de las aplicaciones usarían BACKUP_ENABLE lugar de simplemente BACKUP .

También están mis ideas del # 3223 que resolverían el problema de escape (para cada caso de uso, no solo directoryvalue ), así como algunas otras cosas.

Ahora he actualizado la propuesta en # 3223. 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

La gran pregunta es quién implementará todo esto. Está bastante lejos del status quo, es decir, mucho trabajo (por sí solo, los cambios de terminología son una gran cantidad de trabajo). Si quieres implementarlo puedes crear un PR con la propuesta y lo comento. De lo contrario, deberíamos dar un paso atrás y pensar en soluciones viables a nuestro alcance.

Por cierto. la primera parte de la propuesta es en realidad un maravilloso tutorial sobre cómo funcionan los nombres clave. Sería increíble tener esto como tutorial. : corazón_deslumbrante:

La gran pregunta es quién implementará todo esto.

Esa es siempre la pregunta ...

Está bastante lejos del status quo, es decir, mucho trabajo (por sí solo, los cambios de terminología son una gran cantidad de trabajo).

Los cambios en la terminología son definitivamente la parte más importante, especialmente el cambio de toda la documentación. Sin embargo, esto no tiene que hacerlo una sola persona. Estos cambios son bastante simples, simplemente tediosos, por lo que cualquiera puede ayudar, incluso sin un conocimiento extenso sobre el código. En su mayor parte, solo equivale a leer toda la documentación y reemplazar apariciones de cosas como "nombre base".

Si quieres implementarlo puedes crear un PR con la propuesta y lo comento. De lo contrario, deberíamos dar un paso atrás y pensar en soluciones viables a nuestro alcance.

Comenzaré un PR, pero no puedo decir si tengo tiempo para terminarlo (solo) en lo previsible.
Ya tengo una sucursal local en la que todas las llamadas a keyBaseName , keySetBaseName y keyAddBaseName han sido reemplazadas por keyLastUnescapedPart , keySetLastUnescapedPart / keySetLastLiteralPart y keyAddUnescapedPart / keyAddLiteralPart . Lo creé usando un regex-replace semiautomático después de escribir la primera propuesta.

Pero en esa rama, las nuevas funciones son solo #define s para las antiguas, por lo que la implementación real aún debe escribirse y luego las pruebas y probablemente los complementos de almacenamiento deben actualizarse.

El mayor problema para mí serían los complementos de almacenamiento. Puedo implementar las actualizaciones en el núcleo y las pruebas y tal vez un complemento de almacenamiento. Pero preferiría no tener que estudiar el código de todos los complementos de almacenamiento y descubrir todas las complejidades de todos los formatos.

Por cierto. la primera parte de la propuesta es en realidad un maravilloso tutorial sobre cómo funcionan los nombres clave. Sería increíble tener esto como tutorial.

Por eso lo escribí de esta manera. Mi plan era reutilizar partes de esta propuesta para la documentación en # 3447. No puedo usarlo 1: 1 porque dejé algunas partes muy importantes (por ejemplo, canónicas frente a no canónicas).

Necesito ser franco y no darle ninguna esperanza equivocada: como vio en LCDproc, no sucede que otros estén saltando hacia adelante completando tareas, especialmente cuando son tediosas. Un PR que destruye todos los complementos de almacenamiento excepto uno no se puede fusionar. Y los complementos de almacenamiento no se benefician mucho de este PR, en realidad se vuelven "peores" en el sentido de que de repente producirán errores de sintaxis en archivos que podrían analizar ahora. Esto no significa que, en general, sea una mala idea. Con algunos refinamientos, podría ser mejor que el statu quo, pero simplemente no veo cómo podemos lograr hacer una tarea tan grande con tantas otras tareas abiertas importantes urgentes que tenemos en este momento.

Así que, por favor, concentrémonos en # 3447 (docu), finalmente terminando # 2969, mejorando el complemento TOML y otros temas importantes que necesitamos para 1.0 (https://github.com/ElektraInitiative/libelektra/milestone/12 y https: // github.com/ElektraInitiative/libelektra/milestone/14). Una vez que esto se vea bien, podemos ver qué otras ideas podemos lograr.

Para mí, la conclusión de esta discusión es que definitivamente hay una necesidad de bibliotecas para facilitar la escritura de complementos de almacenamiento, ya que el enfoque de complementos no funcionó (excepto para el binario). Esta conclusión debería estar en el tutorial del complemento de almacenamiento.
@ bauhaus93 ¿ puede tomar la tarea de continuar con el tutorial del complemento de almacenamiento? Ahora tiene mucha información, que no se puede ver al mirar el código fuente del complemento toml.

Un PR que destruye todos los complementos de almacenamiento excepto uno no se puede fusionar.

No esperaba que nadie fusionara un PR ... Solo dije que sería bueno si otras personas pudieran ayudar con las actualizaciones de los complementos de almacenamiento. Idealmente, el autor original del complemento. Después del # 3491, algunos de los complementos de almacenamiento más complejos se eliminarán de todos modos, por lo que toda la tarea será más fácil.

Y los complementos de almacenamiento no se benefician mucho de este PR, en realidad se vuelven "peores" en el sentido de que de repente producirán errores de sintaxis en archivos que podrían analizar ahora.

Éste no debería ser el caso. Incluso hay una explicación parcial al final de la propuesta . Que yo sepa no debería ser un caso, donde un plug-in de almacenamiento debe rechazar un archivo, ya que no se puede traducir en un KeySet .

La única excepción serían los formatos, que utilizan directamente los nombres clave de Elektra (con escape o sin escape). Estos podrían aceptar menos archivos después de esta propuesta que antes. Pero dado que la sintaxis de estos archivos siempre dependió de la sintaxis de los nombres de clave, esto es completamente de esperar.

Con algunos refinamientos, podría ser mejor que el statu quo, pero simplemente no veo cómo podemos lograr hacer una tarea tan grande con tantas otras tareas abiertas importantes urgentes que tenemos en este momento.

Nunca esperé que esta propuesta fuera adoptada de inmediato. Pero creo que definitivamente deberíamos considerar implementarlo antes de 1.0. Una vez que se publique la versión 1.0, la propuesta sería un gran cambio radical. No creo que lanzar una versión 2.0 incluso 1 o 2 años después de la 1.0 (no importa antes) sería una buena idea, considerando el público objetivo de Elektra.

Así que, por favor, concentrémonos en # 3447 (docu), finalmente terminando # 2969, mejorando el complemento TOML y otros temas importantes que necesitamos para 1.0

Estoy totalmente de acuerdo. Pero nuevamente, deberíamos considerarlo, porque después de que se publique 1.0, agregar cambios importantes será muy difícil durante bastante tiempo.

Para mí, la conclusión de esta discusión es que definitivamente hay una necesidad de bibliotecas para facilitar la escritura de complementos de almacenamiento.

👍

excepto el binario se ve

En mi opinión, el caso de los valores binarios es muy diferente. Es una traducción de valor clave 1: 1, como muchas otras ( rgbcolor , macaddr , ipaddr , etc.), por lo que un complemento es realmente adecuado aquí. Sin embargo, como dije, una nueva API de complemento que se ocupa de una sola clave a la vez podría ser una mejora. Pero eso se puede agregar fácilmente después de la versión 1.0, ya que no sería un cambio importante si se hiciera correctamente.

la mayoría -> debe?

Sí, lo veo de la misma manera: no es realista que este cambio ocurra una vez que 1.0 esté fuera (el propósito de 1.0 es congelar tales decisiones para que otros puedan confiar en él) y sería bueno tener tales mejoras antes . Pero como se dijo: realmente necesitamos concentrarnos en hacer las cosas críticas y no perder nuestra energía en batallas agradables que no podemos ganar con nuestra mano de obra actual.