Libelektra: Bibliothèque de types

Je pense que ce devrait être le moyen exceptionnel de constituer des bibliothèques sur la base de propositions. Il est beaucoup plus logique d'extraire des fonctionnalités communes entre les plugins et d'en faire une bibliothèque. Le plugin TOML de @bauhaus93 contient des tonnes de code qui aurait beaucoup de sens à être mis dans une bibliothèque (par exemple, le code de gestion des commentaires).

Ne vous méprenez pas, c'est une bonne contribution à @bauhaus93. Et s'il existe un deuxième plugin qui a besoin de la même fonctionnalité, nous devons absolument le mettre dans une bibliothèque. Mais créer des bibliothèques demande beaucoup plus d'efforts que d'avoir du code spécifique à un plugin et l'effort ne devrait être fait que s'il y a réellement au moins deux clients.

@bauhaus93 si vous ne voyez pas d'avantage immédiat à avoir une bibliothèque de types (par exemple, la réutilisation avec un autre plugin), veuillez fermer le problème.

s'il y a un deuxième plugin qui a besoin de la même fonctionnalité, nous devons absolument le mettre dans une bibliothèque

Tant que le développeur du deuxième plugin sait où trouver le premier plugin et comment en extraire le code sans tout casser, c'est une bonne stratégie oui. Malheureusement, ce n'est souvent pas le cas. D'autant plus que souvent le premier plugin doit être considérablement modifié pour qu'il puisse utiliser une bibliothèque.

Le fait d'avoir la bibliothèque peut également encourager quelqu'un à écrire un nouveau plugin de stockage, car une partie du travail est déjà effectuée.

Mais j'ai marqué cela comme low priority , exactement parce que je savais que c'était beaucoup de travail et qu'il n'y avait probablement personne qui veuille le faire.

Pour les types, je ne suis pas sûr de la réutilisabilité, sauf peut-être pour la validation/conversion d'entiers non décimaux (binaire/octal/hexadécimal) ou les datetimes (TOML utilise les datetimes RFC 3339).
Sans rapport avec les types, je vois une certaine réutilisabilité dans la préparation des KeySets à écrire (par exemple, des fonctions qui mettent à jour/ajoutent des métaclés array , suppriment les métaclés array des tableaux invalides ou complètent les comment/#X manquants

Vous ne l'avez peut-être pas encore remarqué, mais il peut également y avoir des problèmes avec la normalisation des booléens que le type plugin fait. C'est probablement le code le plus réutilisé, car la plupart des formats utiliseront true / false mais Elektra utilise 1 / 0 . Je pense que yamlcpp a dû ajouter du code spécial, afin que les booléens ne soient pas convertis en entiers ou vice-versa (ou quelque chose du genre).

Ah ouais, oublié ça, le plugin TOML doit aussi normaliser ces valeurs.

Le problème n'est pas seulement qu'il faut normaliser les valeurs. Vous devez aussi savoir exactement ce que le type plug - in ne, car il fonctionne avant le toml Plug - in dans le kdbSet phase. Je ne sais pas si nous l'avons déjà implémenté, mais vous devez également vous assurer que le plugin type ne produit que 1 / 0 ou true / false dans la phase kdbSet , quelle que soit la configuration fournie par l'utilisateur. Sinon, toml devrait être capable d'analyser la configuration du plugin type , car l'utilisateur peut définir des valeurs true et false personnalisées (voir le cas de test ci-dessous)

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

La partie intéressante est :

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

Le plugin type reçoit un 1 dans kdbGet (peut provenir de toml ), mais renvoie un t dans kdbSet . Cela pourrait aller jusqu'à ce qu'un utilisateur définisse cela true = 0 et false = 1 ce qui confondrait totalement le plugin toml . (Je pense que tous les booléens se retourneraient tous les kdbSet )

Cette interaction extrêmement complexe est la raison pour laquelle je pense que le plugin type devrait être destiné aux formats de stockage qui n'ont pas de types et ceux qui en ont devraient interdire explicitement l'utilisation de type . Mais pour rendre cela possible, nous avons besoin d'un moyen simple de prendre en charge les types dans les plugins de stockage, c'est-à-dire une bibliothèque de types.

Étant donné que le plugin toml gère également les nombres hexadécimaux, il devrait probablement aussi interdire explicitement l'utilisation du plugin hexnumber . (bien que dans ce cas il y ait moins de problèmes potentiels je pense)

Le fait d'avoir la bibliothèque peut également encourager quelqu'un à écrire un nouveau plugin de stockage, car une partie du travail est déjà effectuée.

La plupart des utilisateurs ne veulent probablement écrire que la grammaire et le reste devrait se produire comme par magie. Je me demande dans quelle mesure le plugin TOML de @bauhaus93 a réellement atteint cet objectif. Ce serait intéressant de faire un plugin non-TOML avec le code-base du plugin TOML. Une bibliothèque de types seule, cependant, me semble beaucoup trop spécialisée pour être trop utile pour la grosse tâche d'"écrire un plugin de stockage".

Pour les types, je ne suis pas sûr de la réutilisabilité, sauf peut-être pour la validation/conversion d'entiers non décimaux (binaire/octal/hexadécimal) ou les datetimes (TOML utilise les datetimes RFC 3339).

La date/l'heure n'existaient dans Elektra que pour la validation, mais seule la RFC2822 était prise en charge. Le plugin de date pourrait réutiliser votre analyseur pour valider la RFC 3339 mais je considérerais cela comme une priorité très faible.

Ce qui serait un peu plus excitant, c'est quelque chose comme keyGetDateTime(Key *k, struct tm *tm) d'une clé avec une date (TOML).

Sans rapport avec les types, je vois une certaine réutilisabilité dans la préparation des KeySets à écrire (par exemple, des fonctions qui mettent à jour/ajoutent des métaclés de tableau, suppriment les métaclés de tableau de tableaux invalides ou complètent les données manquantes de commentaire/métakey #X).

Oui, ça peut être intéressant. Mais encore plus fascinante serait la possibilité de modifier directement la grammaire et de toucher le moins possible le code :wink:

Vous ne l'avez peut-être pas encore remarqué, mais il peut également y avoir des problèmes avec la normalisation des booléens que le type plugin fait.

Ce qui manque, c'est un tutoriel/une explication dans doc/tutorials/storage-plugins.md qui donne une vue à jour des plugins sur lesquels un plugin de stockage devrait réellement s'appuyer. #2330 montrera si "binaire" peut être nécessaire et convient toujours comme stockage par défaut.

Vous devez également savoir exactement ce que fait le plugin type, car il s'exécute avant le plugin toml dans la phase kdbSet.

Probablement, les plugins de stockage devraient cesser d'utiliser le plugin de type et simplement faire leur normalisation eux-mêmes (de tout ce qui est vrai/faux dans leur format à 1/0 dans Elektra et ainsi de suite). @bauhaus93 quelle autre fonctionnalité du type plugin utilisez-vous ?

Cela pourrait aller jusqu'à un utilisateur définissant que true = 0 et false = 1 ce qui confondrait totalement le plugin toml.

Je serais favorable à la réduction des fonctionnalités du type plugin. Si quoi que ce soit, certaines valeurs vrai/faux supplémentaires devraient être définissables par l'utilisateur (qui n'étaient évidemment pas des valeurs vrai/faux auparavant).

Étant donné que le plugin toml gère également les nombres hexadécimaux, il devrait probablement également interdire explicitement l'utilisation du plugin hexnumber. (bien que dans ce cas il y ait moins de problèmes potentiels je pense)

Il n'y a aucun moyen d'exprimer que les plugins ne fonctionnent pas ensemble (Avoir une telle fonctionnalité rendrait le montage beaucoup plus compliqué. Ce serait aussi trop de travail pour nous de maintenir une table de quel plugin fonctionne avec quel plugin.). Mais personne n'aura probablement l'idée de les utiliser ensemble, car le plugin TOML a déjà cette fonctionnalité et plus (par exemple aussi les nombres binaires).

La plupart des utilisateurs ne veulent probablement écrire que la grammaire et le reste devrait se produire comme par magie.

Cela semble un peu trop magique pour être possible. Cela pourrait être possible avec un générateur de code personnalisé basé sur une grammaire Yacc ou ANTLR modifiée. Mais je ne pense pas qu'il existe un moyen d'avoir un code qui crée des KeySet s simplement à partir d'une grammaire pour des formats très différents comme JSON, XML, TOML et edn . Comme @'sanssecours l'a trouvé, il existe également des formats comme YAML qui sont très difficiles à exprimer dans un format grammatical standard.

Une bibliothèque de types seule, cependant, me semble beaucoup trop spécialisée pour être trop utile pour la grosse tâche d'"écrire un plugin de stockage".

Nous pourrions bien sûr étendre la bibliothèque en une bibliothèque générale storage qui fournit plus de fonctions d'assistance pour les plugins de stockage (par exemple, traitant de stdin / stdout et des tuyaux pour l'import/export). Les trucs de type feraient alors partie de cela.

Je pense aussi que vous sous-estimez à quel point les trucs de type peuvent être compliqués. Si nous avions une bibliothèque de types standard, l'extension du système de types serait également plus facile, par exemple pour stocker des versions binaires pré-analysées d'entiers en plus (aux versions de chaîne pour réduire la surcharge d'analyse). Une bibliothèque storage pourrait également utiliser des API internes (si nécessaire), car elle est maintenue par les développeurs d'Elektra.

Une autre bibliothèque de types standard garantirait également des messages d'erreur standard pour les problèmes de type. Il y aurait donc même un avantage pour les utilisateurs finaux.

Ce qui serait un peu plus excitant, c'est quelque chose comme keyGetDateTime(Key *k, struct tm *tm)

Cela ressemble à un travail pour la partie conversion de libease (comme elektraKeyToDateTime (const Key * key, struct tm * dateTime) ).

@bauhaus93 les fonctions là-bas pourraient également être utiles pour toml . Ils sont conçus de telle sorte que par exemple elektraKeyToFloat et elektraFloatToString aller-retour parfaitement et sans perte (peu importe si vous commencez avec un flottant d'une chaîne) et ils sont également utilisés dans l'API de haut niveau. Donc, si toml crée la clé avec elektra*ToString elle peut certainement être lue correctement par l'API de haut niveau et toml peut définitivement lire correctement quelle que soit l'API highlevel produite avec elektraKeyTo* .

une vue à jour des plugins sur lesquels un plugin de stockage devrait réellement s'appuyer.

IMO, un plugin de stockage ne doit jamais _s'appuyer_ sur un autre plugin. Les plugins de stockage peuvent être améliorés par d'autres plugins, mais ils devraient idéalement fonctionner de manière autonome.

Même le traitement des clés binaires serait mieux résolu par une bibliothèque de stockage/type. Encore une fois, cela garantit une norme de base pour les messages d'erreur, etc. Cela évite également l'utilisation du plugin binary pour les formats qui n'en ont pas besoin. Alors que binary combiné avec par exemple quickdump fonctionnerait, c'est mauvais pour la vitesse et la taille de stockage.

Probablement, les plugins de stockage devraient cesser d'utiliser le plugin de type et simplement faire leur normalisation simplement eux-mêmes

C'est pourquoi j'ai proposé une bibliothèque. C'est bien mieux de fournir une bibliothèque qui fait le travail que de simplement donner une description informelle (ou même une spécification formelle) de ce que le plugin doit faire. Surtout si la spécification peut changer avec le temps.

Je serais favorable à la réduction des fonctionnalités du type plugin.

Pourquoi supprimer des fonctionnalités déjà implémentées ? À l'origine, l'idée était d'avoir un plugin boolean séparé, mais cela causait également des problèmes, à cause de l'ordre des plugins et de ce genre de choses.

Si quoi que ce soit, certaines valeurs vrai/faux supplémentaires devraient être définissables par l'utilisateur (qui n'étaient évidemment pas des valeurs vrai/faux auparavant).

Il n'y a vraiment pas besoin de ça. Il n'y a un problème que si plus d'un plugin définit ce qu'est une valeur booléenne.

Même true = 0 et false = 1 sont tout à fait corrects. Elektra lui-même inflige des amendes aux booléens car " 1 est la seule vraie valeur et 0 est la seule fausse valeur".

Il n'y a aucun moyen d'exprimer que les plugins ne fonctionnent pas ensemble (Avoir une telle fonctionnalité rendrait le montage beaucoup plus compliqué. Ce serait aussi trop de travail pour nous de maintenir une table de quel plugin fonctionne avec quel plugin.).

Je ne suis pas d'accord. Une liste exhaustive serait bien sûr impossible (après tout il existe aussi des plugins tiers), mais la solution est simple. Laissez les plugins faire le contrôle eux-mêmes. Soit dans elektra<Plugin>Get soit dans une autre fonction appelée pendant kdb mount .

Outre le booléen, le plugin TOML définit également les types string, double et (unsigned_)long_long lors de la lecture.

Je suis d'accord avec @kodebach , que le plugin type ne doit être utilisé que par des plugins sans système de type intégré, à cause des difficultés d'interaction.
Par exemple. le plugin TOML définit la métaclé type pour les entiers lors de la lecture également sur des valeurs non décimales (tout en la convertissant en décimale, en stockant la représentation non décimale dans origvalue ). Cependant, si vous souhaitez modifier une telle valeur saisie avec kdb set (et le faire par valeur binaire/octal/hex), vous ne pouvez pas le faire directement (en définissant la valeur de la clé), car le type les vérifications du type de plug-in n'aboutiraient pas. Vous devrez plutôt changer la métaclé origvalue . (Supprimer la métaclé type avant de définir une nouvelle valeur ne fonctionnerait pas, car la métaclé sera réinitialisée à la lecture.)

Le problème n'est pas seulement qu'il faut normaliser les valeurs. Vous devez également savoir exactement ce que fait le plugin type, car il s'exécute avant le plugin toml dans la phase kdbSet. Je ne sais pas si nous l'avons déjà implémenté, mais vous devez également vous assurer que le plugin de type ne produit jamais que 1/0 ou vrai/faux dans la phase kdbSet, quelle que soit la configuration fournie par l'utilisateur. Sinon, toml devrait être capable d'analyser la configuration du plugin de type, car l'utilisateur peut définir des valeurs true et false personnalisées (voir le cas de test ci-dessous)

Oui, je me suis déjà demandé si/comment je pouvais vérifier les valeurs booléennes définies par l'utilisateur. Actuellement, lors de l'écriture, le plugin TOML ne considère que les valeurs de "1" et "true" comme vraies, le reste serait considéré comme faux.

@kodebach a écrit :

Cela semble un peu trop magique pour être possible.

Avec Augeas c'est possible (mais les arbres que vous obtenez ne sont pas si désirables). Il serait intéressant de savoir à quel point nous en sommes avec la solution TOML actuelle. Bien sûr, vous devez écrire du code d'émetteur, mais ce n'est généralement pas si dramatique.

JSON, XML

C'est l'avantage d'Elektra que des formats si différents peuvent être mis en œuvre dans différentes technologies. Essayer d'implémenter XML à partir de zéro n'est probablement pas la meilleure idée. Si les formats de type INI pouvaient être couverts, ce serait déjà incroyable.

Mais bien sûr, la première et la plus importante chose est d'avoir un bon plugin TOML : 1st_place_medal :

Une autre bibliothèque de types standard garantirait également des messages d'erreur standard pour les problèmes de type.

La vérification peut se faire facilement dans d'autres plugins (une fois le #2963 fait). Si un plugin ne fait que vérifier et échouer avec un beau message d'erreur, il y a peu/pas d'interactions.

Cela ressemble à un travail pour la partie conversion de libease

Oui, probablement certaines des choses de TOML pourraient aller à libease ou libmeta.

OMI, un plugin de stockage ne doit jamais s'appuyer sur un autre plugin.

Pour le binaire, je ne suis pas encore sûr (car c'est probablement quelque chose qui n'est pas nécessaire pour les backends par défaut), pour toutes les autres fonctionnalités, c'est aussi ma conclusion. Cependant, cette conclusion n'est pas encore largement acceptée (@sanssecours?) ni documentée.

C'est pourquoi j'ai proposé une bibliothèque. C'est bien mieux de fournir une bibliothèque qui fait le travail que de simplement donner une description informelle (ou même une spécification formelle) de ce que le plugin doit faire. Surtout si la spécification peut changer avec le temps.

Cela dépend : s'il y a un grand nombre de possibilités valides, un tutoriel/description peut être mieux qu'une bibliothèque compliquée qui essaie d'une manière ou d'une autre de donner cette flexibilité. Et pour les sérialisations, il existe une vaste gamme de possibilités valides et beaucoup d'entre elles ont des implémentations triviales (par exemple, en appelant simplement elektraFormat avec certains paramètres) jusqu'à des implémentations compliquées (par exemple si elles prennent en charge de nombreuses représentations pratiques).

Pourquoi supprimer des fonctionnalités déjà implémentées ?

Elektra s'effondre actuellement sur le poids de la maintenance de trop de code. Chaque ligne de code inutile (au sens où personne ne l'utilise) dont nous nous débarrassons rend Elektra meilleur.

Malheureusement, même le code séparé dans les plugins crée des problèmes : par exemple sur le serveur de construction ou une fois qu'un utilisateur essaie de l'utiliser, il y a des interactions indésirables/un document manquant/...

Nous ne pouvons pas publier tout ce que nous avons actuellement en version 1.0, Elektra serait alors une déception. Nous devons nous débarrasser de tout ce qui n'est pas nécessaire. Nous apprécions chaque nettoyage que vous pouvez faire.

C'est aussi la raison pour laquelle TOML remplacera INI. #3491

Laissez les plugins faire le contrôle eux-mêmes.

C'était rarement une bonne solution. Cela devient très incohérent et l'ordre d'ajout des plugins peut produire des résultats différents. Un tel code existe-t-il déjà quelque part ?

@bauhaus93 a écrit :

Outre le booléen, le plugin TOML définit également les types string, double et (unsigned_)long_long lors de la lecture.

Mais tout se fait tout seul sans le type plugin ? A quoi sert le plugin type ?

Vous devrez plutôt modifier la métaclé origvalue.

Oui, ici nous n'avons pas encore de solution sympa (#3056). keySetString supprime origvalue mais d'une manière ou d'une autre, le comportement n'est toujours pas celui auquel un utilisateur s'attendrait.

Actuellement, lors de l'écriture, le plugin TOML ne considère que les valeurs "1" et "true" comme vraies, le reste serait considéré comme faux.

Nous devrions probablement être plus stricts et échouer sur tout ce qui n'est pas « 0 » ou « 1 ». Dans le fichier TOML lui-même, vous n'autorisez également que "vrai" et "faux" et rien d'autre ?

Mais tout se fait tout seul sans le type plugin ? A quoi sert le plugin type ?

Oui, il le fait tout seul, les différents types seront appariés pendant le lexing. Cependant, il ne vérifie pas si les valeurs décimales/doubles dépassent/sous-dépassent long_long / double , donc je pense que c'est fait par le plugin type .

Nous devrions probablement être plus stricts et échouer sur tout ce qui n'est pas « 0 » ou « 1 ». Dans le fichier TOML lui-même, vous n'autorisez également que "vrai" et "faux" et rien d'autre ?

Oui, je peux rendre cela plus strict. Dans le fichier lui-même, seul true ou false est écrit/lu comme booléen.

pour toutes les autres fonctionnalités, c'est aussi ma conclusion.

Dans ce cas, nous avons besoin d'une bibliothèque type . Sinon, tout plugin de stockage pour un format avec des types aurait réimplémenté le type stuff (puisque s'appuyer sur un autre plugin est hors de question).

s'il y a un grand nombre de possibilités valables, un tutoriel/description pourrait être mieux

Mais dans ce cas, un plugin séparé n'est pas non plus la solution, car alors il y a aussi un grand nombre d'interactions possibles qui doivent être prises en compte dans les deux plugins.

Un tel code existe-t-il déjà quelque part ?

AFAIK, je ne suis même pas sûr qu'un plugin puisse détecter quels autres plugins sont montés.

Mais tout se fait tout seul sans le type plugin ? A quoi sert le plugin type ?

Oui, il le fait tout seul, les différents types seront appariés pendant le lexing. Cependant, il ne vérifie pas si les valeurs décimales/doubles débordent/dépassent long_long / double , donc je pense que c'est fait par le plugin type .

Oui, type également une vérification de plage, valide float / double et d'autres choses comme enum s.

Nous devrions probablement être plus stricts et échouer sur tout ce qui n'est pas « 0 » ou « 1 ». Dans le fichier TOML lui-même, vous n'autorisez également que "vrai" et "faux" et rien d'autre ?

Et c'est exactement l'un de ces cas extrêmement complexes et compliqués pour les types ou plus précisément la conversion/normalisation.

Supposons que toml n'accepte que true / false en entrée et ne produit que 0 / 1 dans kdbGet et n'accepte que 0 / 1 et ne produit que true / false en kdbSet . Cela serait conforme à la fois à la spécification Elektra et à la spécification TOML pour les booléens. Mais un utilisateur s'attendrait probablement à ce que kdb set /some/key/mounted/with/toml true fonctionne. Cependant, ce n'est pas le cas. Avec la bonne configuration pour type cela peut fonctionner, mais cela devient vite gênant. Par exemple, que se passe-t-il si la clé existait auparavant. Ensuite, il n'y a pas type métaclé type l'ignore simplement, toml reçoit true et se plaint que true n'est pas valide booléen...

Cela montre simplement qu'un plugin de stockage DOIT être capable de gérer tous les types pris en charge par le format de stockage et les conversions associées SANS utiliser d'autres plugins.

Elektra s'effondre actuellement sur le poids de la maintenance de trop de code. Chaque ligne de code inutile (au sens où personne ne l'utilise) dont nous nous débarrassons rend Elektra meilleur.

C'est un point juste, même si je ne pense pas que la simple suppression du code soit la bonne solution. Du moins pas en ce qui concerne les plugins. Dans le noyau, je suis d'accord, moins il y a de LOC, mieux c'est. Pour les plugins, on peut facilement dire que le plugin ou une partie de celui-ci est expérimental.

OMI, un plugin de stockage ne doit jamais s'appuyer sur un autre plugin.

Cependant, cette conclusion n'est pas encore largement acceptée (@sanssecours?) ni documentée.

Pour autant que je sache, il n'y a aucun endroit dans la documentation qui indique qu'un plugin de stockage ne doit pas s'appuyer sur d'autres plugins. Je ne pense pas non plus que ce soit formidable du point de vue de la séparation des préoccupations. Écrire un bon plugin de stockage est déjà beaucoup de travail à mon avis. Exiger qu'un plugin de stockage s'occupe de la conversion de type, des clés de répertoire et des données binaires (codage Base64) ne facilite pas cette tâche.

Je ne pense pas non plus que ce soit formidable du point de vue de la séparation des préoccupations. Écrire un bon plugin de stockage est déjà beaucoup de travail à mon avis.

C'est le but de la bibliothèque d'aide. Il sépare le code commun et fournit ainsi une (certaine) séparation des préoccupations tout en facilitant le développement du plugin.

Concernant la préoccupation de @markus2330 selon laquelle le développement d'une bibliothèque à usage général est plus difficile qu'un plugin similaire : c'est faux, car vous pourriez simplement fournir une version légèrement modifiée de la fonction elektraTypeGet tant que bibliothèque. Les modifications ne sont nécessaires que parce que nous devons remplacer le Plugin * handle par un KeySet * config . Bien que cela ne résolve pas tous les problèmes, cela permet au moins au plug-in de stockage de contrôler exactement comment et quand le type est effectué.

Par exemple, toml pourrait avoir un mode de secours INI où il n'utilise pas le système de type TOML mais s'en remet à type et un mode TOML normal où il fournit elektraTypeGet avec une configuration très précise qui garantit que tout est conforme à la spécification TOML.

En bref, une bibliothèque est simple beaucoup plus flexible qu'un plugin du point de vue du plugin de stockage. Au moins avec les possibilités de configuration de plugin actuelles.

Exiger qu'un plugin de stockage s'occupe de la conversion de type, des clés de répertoire et des données binaires (codage Base64) ne facilite pas cette tâche.

Décomposons ceci :

• Données binaires : il n'y a pas vraiment d'effort à faire pour faire quelque chose comme :
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  Un plugin séparé fonctionnerait également, tant que le plugin de stockage peut imposer que l'autre plugin est monté en toutes circonstances et peut simplement supposer qu'il n'y a pas de clés binaires. Si le plugin doit toujours appeler keyIsBinary et générer une erreur, il n'y a aucun avantage à cette solution. Je n'aime pas non plus le fait qu'un plugin binaire séparé doive convertir l'ensemble de KeySet à la fois, car alors toutes les clés Base64 gaspillent pas mal de mémoire.
• Clés de répertoire : d'abord, ces clés non-feuille avec des valeurs sont étranges dans presque toutes les circonstances et nous devrions en fait recommander de les éviter. En ce qui concerne le traitement de ces clés, comme indiqué dans #3256, je pense qu'une bibliothèque est bien mieux adaptée à ce cas. Il existe de nombreuses raisons, notamment la surcharge de mémoire et de traitement, qui compliquent inutilement les configurations et la flexibilité des points de montage. Il semble que @markus2330 (un peu) soit d'accord avec moi sur ce point.
• Types : tout plugin de stockage pour un format qui a un système de type natif devra faire au moins un peu de travail pour les types. Cela peut aller de la conversion complète à partir de zéro à l'appel d'une bibliothèque à la configuration d'un autre plugin. Il ne sera

Cependant, il ne vérifie pas si les valeurs décimales/doubles débordent/débordent long_long/double, donc je pense que c'est fait par le typeplugin.

Ok, donc vous ne l'utilisez essentiellement que pour vérifier.

Mais dans ce cas, un plugin séparé n'est pas non plus la solution

Non, les plugins séparés ne sont malheureusement pas la solution. Nous avons échoué là-bas. La solution actuelle est que chaque plugin de stockage implémente tout (sauf la gestion binaire) basé sur doc/tutorials/storage-plugins.md

Mais un utilisateur s'attendrait probablement à ce que kdb set /some/key/mount/with/toml true fonctionne.

Non, un utilisateur ne doit pas s'attendre à cela. Dans Elektra, 1/0 est vrai/faux. Seuls les plugins de stockage peuvent mapper cela à autre chose.

Justification : Comme au moins au niveau de la spécification, seuls 1/0 fonctionnent, il ne serait que déroutant de faire fonctionner vrai/faux ailleurs (à l'exception des plug-ins de stockage).

Cela montre simplement qu'un plugin de stockage DOIT être capable de gérer tous les types pris en charge par le format de stockage et les conversions associées SANS utiliser d'autres plugins.

Oui je suis d'accord.

C'est un point juste, même si je ne pense pas que la simple suppression du code soit la bonne solution.

Bien sûr, nous devons supprimer le "bon" code : celui qui vous donne des attentes sans le remplir ou introduire des problèmes avec d'autres parties d'Elektra. Et certaines fonctionnalités du type plugin semblent créer des problèmes avec d'autres parties d'Elektra.

Du moins pas en ce qui concerne les plugins. Dans le noyau, je suis d'accord, moins il y a de LOC, mieux c'est. Pour les plugins, on peut facilement dire que le plugin ou une partie de celui-ci est expérimental.

Malheureusement, cela ne fonctionne pas (encore*). Les gens ne jugent pas correctement le statut des plugins, par exemple, voir récemment : #3472 où le plugin INI non maintenu et buggé, et pire encore, le plugin xmltool hérité déconseillé, étaient censés fonctionner parfaitement.

• Cela pourrait mieux fonctionner si je retravaille #666 et que nous émettons des avertissements pendant le montage.

Exiger qu'un plugin de stockage s'occupe de la conversion de type, des clés de répertoire et des données binaires (codage Base64) ne facilite pas cette tâche.

@sanssecours comment les plugins YAML gèrent la conversion de type ?

C'est faux en fait

On verra quand ce sera fait :stuck_out_tongue_winking_eye:

En bref, une bibliothèque est simple beaucoup plus flexible qu'un plugin du point de vue du plugin de stockage. Au moins avec les possibilités de configuration de plugin actuelles.

Personne ne s'est disputé à ce sujet. Mais la flexibilité a parfois un prix énorme.

Il n'y a pas vraiment d'effort à faire pour faire quelque chose comme

base64 n'est pas le seul moyen d'encoder des données binaires. Pour les normes où la base64 est requise, elle peut être codée en dur. ( @sanssecours Est-ce le cas pour YAML ?)

Pour TOML cependant, il dit simplement "Base64 ou un autre codage ASCII ou UTF-8 approprié", donc d'autres plugins binaires pourraient être utilisés. La solution actuelle présente donc des avantages, car les utilisateurs peuvent monter d'autres plugins binaires selon leurs souhaits ou leurs besoins.

@bauhaus93 - infos/needs = base64 doit être remplacé par - infos/needs = binary .

Tout d'abord, ces clés non-feuille avec des valeurs sont étranges dans presque toutes les circonstances et nous devrions en fait recommander de les éviter.

Il y en a très commun dans de nombreux formats. Et ils peuvent être très utiles lorsque vous étendez une spécification (créez des sous-clés à partir de clés qui avaient des valeurs).

[Clés de répertoire] Il semble que @markus2330 soit (un peu) d'accord avec moi sur ce point.

Je suis d'accord sur le fait que les plugins de stockage doivent le gérer (peut-être avec une bibliothèque mais pas avec le plugin "directoryvalue" car l'échappement ne fonctionne pas et l'échappement correct est l'une des tâches principales d'un plugin de stockage).

Ok, donc vous ne l'utilisez essentiellement que pour vérifier.

Je ne suis pas d'accord avec l'expression "le plugin toml utilise le plugin type ". Dans la version actuelle, il ne recommande que type .

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

Même si type était déclaré comme needs , je ne l'appellerais pas "using". toml n'a pas vraiment de contrôle direct sur type . C'est pourquoi j'ai dit que toml repose sur type . Il s'attend type ce que

Cela pourrait mieux fonctionner si je retravaille #666 et que nous émettons des avertissements pendant le montage.

Je suis d'accord. Peut-être même tous les kdbGet , à moins qu'une clé spéciale "Je reconnais que ce point de montage utilise des plugins expérimentaux" n'ait été définie.

base64 n'est pas le seul moyen d'encoder des données binaires.

C'est en fait un argument pour un plugin binary . Bien que je souhaite toujours une interface à travers laquelle le plugin peut fonctionner sur une seule touche à la fois, cela pourrait permettre de réaliser des économies de mémoire et peut-être également des économies de performances. (Mais c'est un autre problème)

Il y en a très commun dans de nombreux formats.

Avez-vous un exemple?

Et ils peuvent être très utiles lorsque vous étendez une spécification (créez des sous-clés à partir de clés qui avaient des valeurs).

C'est vrai, mais dans ce cas, je recommanderais une solution "soit ou" (à partir du POV de l'utilisateur final). Soit vous utilisez l'ancienne clé avec la valeur unique, soit vous utilisez la nouvelle version avec des sous-clés. Sinon, la configuration sera probablement déroutante.

Pour être clair, je ne pense pas que les clés non-feuille avec des valeurs ne devraient jamais être utilisées, mais elles devraient être évitées si possible et sont rarement (voire jamais) la solution préférée.

mais pas avec le plugin "directoryvalue" car l'échappement ne fonctionne pas

Dans #3256, j'ai suggéré l'utilisation de métadonnées pour résoudre les problèmes d'échappement. Il y a aussi mes idées de #3223 qui résoudraient le problème d'échappement (pour chaque cas d'utilisation pas seulement directoryvalue ) ainsi que d'autres choses. Voir aussi la proposition (très formelle) . J'ajouterai des explications en anglais simple aujourd'hui ou demain à ce document, car je suis toujours très favorable à ces changements.

@sanssecours comment les plugins YAML gèrent la conversion de type ?

Yan LR et YAML CPP utilisent le plugin type pour les booléens. YAML CPP utilise également le plugin base64 pour les données binaires.

base64 n'est pas le seul moyen d'encoder des données binaires. Pour les normes où la base64 est requise, elle peut être codée en dur. ( @sanssecours Est-ce le cas pour YAML ?)

Oui, pour autant que je sache, les données binaires en YAML utilisent toujours l'encodage Base64.

[clés non-feuille avec valeurs] Avez-vous un exemple ?

XML et la plupart des dialectes INI (car ils autorisent key=value même lorsque [key] existe)

C'est vrai, mais dans ce cas, je recommanderais une solution "soit ou" (à partir du POV de l'utilisateur final). Soit vous utilisez l'ancienne clé avec la valeur unique, soit vous utilisez la nouvelle version avec des sous-clés. Sinon, la configuration sera probablement déroutante.

Oui, cela semble raisonnable. Une fois que vous savez que quelque chose est une section, vous déplacez généralement la valeur quelque part dans la section.

Par exemple, deluser.conf a BACKUP = 0 et BACKUP_TO = "." . Avec les sections, la plupart des applications utiliseraient BACKUP_ENABLE au lieu de simplement BACKUP .

Il y a aussi mes idées de #3223 qui résoudraient le problème d'échappement (pour chaque cas d'utilisation pas seulement directoryvalue ) ainsi que d'autres choses.

J'ai maintenant mis à jour la proposition dans #3223. J'espère que c'est maintenant plus facile à comprendre (c'est encore très long).

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

La grande question est de savoir qui mettra tout cela en œuvre. On est assez loin du statu quo, c'est-à-dire beaucoup de travail (à eux seuls les changements de terminologie représentent une énorme quantité de travail). Si vous souhaitez la mettre en œuvre, vous pouvez créer un PR avec la proposition et je la commente. Sinon, nous devrions prendre du recul et réfléchir à des solutions réalisables à notre portée.

D'ailleurs. la première partie de la proposition est en fait un merveilleux tutoriel sur le fonctionnement des noms de clé. Ce serait génial d'avoir ça comme tuto. :sparkling_heart:

La grande question est de savoir qui mettra tout cela en œuvre.

C'est toujours la question...

On est assez loin du statu quo, c'est-à-dire beaucoup de travail (à eux seuls les changements de terminologie représentent une énorme quantité de travail).

Les changements de terminologie sont certainement la plus grande partie, en particulier la modification de toute la documentation. Cependant, cela ne doit pas être fait par une seule personne. Ces changements sont assez simples, ils sont simplement fastidieux, donc n'importe qui peut aider, même sans connaissance approfondie du code. Pour la plupart, cela revient simplement à lire toute la documentation et à remplacer les occurrences de choses comme "nom de base".

Si vous souhaitez la mettre en œuvre, vous pouvez créer un PR avec la proposition et je la commente. Sinon, nous devrions prendre du recul et réfléchir à des solutions réalisables à notre portée.

Je vais commencer un PR, mais si j'ai le temps de le terminer (seul) dans le prévisible, je ne peux pas dire.
J'ai déjà une branche locale dans laquelle tous les appels à keyBaseName , keySetBaseName et keyAddBaseName ont été remplacés par keyLastUnescapedPart , keySetLastUnescapedPart / keySetLastLiteralPart et keyAddUnescapedPart / keyAddLiteralPart . Je l'ai créé à l'aide d'un regex-remplace semi-automatique après avoir écrit la première proposition.

Mais dans cette branche, les nouvelles fonctions ne sont que des #define s pour les anciennes, donc l'implémentation réelle doit encore être écrite, puis les tests et probablement les plugins de stockage doivent être mis à jour.

Le plus gros problème pour moi serait les plugins de stockage. Je peux implémenter les mises à jour du noyau et les tests et peut-être un plugin de stockage. Mais je préférerais, si je n'ai pas à étudier le code de tous les plugins de stockage et comprendre toutes les subtilités de tous les formats.

D'ailleurs. la première partie de la proposition est en fait un merveilleux tutoriel sur le fonctionnement des noms de clé. Ce serait génial d'avoir ça comme tuto.

C'est pourquoi je l'ai écrit de cette façon. Mon plan était de réutiliser des parties de cette proposition pour la documentation dans #3447. Je ne peux pas l'utiliser 1:1 car j'ai omis des parties très importantes (par exemple canoniques vs non canoniques).

Je dois être franc et ne pas vous donner de faux espoirs : comme vous l'avez vu dans LCDproc, il n'arrive pas que d'autres se précipitent pour terminer des tâches, surtout pas lorsqu'elles sont fastidieuses. Un PR qui détruit tous les plugins de stockage sauf un n'est pas fusionnable. Et les plugins de stockage ne tirent pas beaucoup d'avantages de ce PR, en fait ils s'aggravent dans le sens où ils produiront soudainement des erreurs de syntaxe sur des fichiers qu'ils pourraient analyser maintenant. Cela ne veut pas dire que c'est globalement une mauvaise idée. Avec quelques améliorations, cela pourrait être mieux que le statu quo, mais je ne vois tout simplement pas comment nous pouvons réussir à faire une tâche aussi importante avec autant d'autres tâches ouvertes urgentes et importantes que nous avons actuellement.

Alors s'il vous plaît, concentrons-nous sur #3447 (docu), pour enfin terminer #2969, améliorer le plugin TOML et d'autres sujets importants dont nous avons besoin pour 1.0 (https://github.com/ElektraInitiative/libelektra/milestone/12 et https:// github.com/ElektraInitiative/libelektra/milestone/14). Une fois que cela semble bon, nous pouvons voir quelles autres idées nous pouvons accomplir.

Pour moi, la conclusion de cette discussion est qu'il y a certainement besoin de bibliothèques pour faciliter l'écriture de plugins de stockage car l'approche plugin ne fonctionnait pas (sauf pour le binaire, c'est à voir). Cette conclusion devrait figurer dans le didacticiel du plugin de stockage.
@bauhaus93 pouvez-vous vous charger de continuer le tutoriel du plugin de stockage ? Vous avez maintenant beaucoup d'informations, ce qui ne peut pas être vu en regardant le code source du plugin toml.

Un PR qui détruit tous les plugins de stockage sauf un n'est pas fusionnable.

Je ne m'attendais pas à ce que quelqu'un fusionne un tel PR... J'ai juste dit que ce serait bien si d'autres personnes pouvaient aider avec les mises à jour des plugins de stockage. Idéalement l'auteur original du plugin. Après #3491, certains des plugins de stockage les plus complexes seront supprimés de toute façon, donc toute la tâche sera plus facile.

Et les plugins de stockage ne tirent pas beaucoup d'avantages de ce PR, en fait ils s'aggravent dans le sens où ils produiront soudainement des erreurs de syntaxe sur des fichiers qu'ils pourraient analyser maintenant.

Cela ne devrait pas être le cas. Il y a même une explication partielle à la fin de la proposition . AFAIK, il ne devrait doit rejeter un fichier, car il ne peut pas être traduit en KeySet .

La seule exception serait les formats, qui utilisent directement les noms de clé d'Elektra (échappés ou non). Ceux-ci pourraient accepter moins de fichiers après cette proposition qu'avant. Mais comme la syntaxe de ces fichiers dépendait toujours de la syntaxe des noms de clé, cela est tout à fait normal.

Avec quelques améliorations, cela pourrait être mieux que le statu quo, mais je ne vois tout simplement pas comment nous pouvons réussir à faire une tâche aussi importante avec autant d'autres tâches ouvertes urgentes et importantes que nous avons actuellement.

Je ne m'attendais pas à ce que cette proposition soit adoptée immédiatement. Mais je pense que nous devrions certainement envisager de l'implémenter avant la version 1.0. Une fois la version 1.0 publiée, la proposition serait un énorme changement de rupture. Je ne pense pas que sortir une version 2.0 même 1 ou 2 ans après la 1.0 (peu importe avant ça) serait une bonne idée, compte tenu du public cible d'Elektra.

Alors, s'il vous plaît, concentrons-nous sur #3447 (docu), pour enfin terminer #2969, améliorer le plugin TOML et d'autres sujets importants dont nous avons besoin pour 1.0

Je suis entièrement d'accord. Mais encore une fois, nous devrions toujours l'envisager, car après la sortie de la 1.0, l'ajout de changements de rupture sera très difficile pendant un certain temps.

Pour moi, la conclusion de cette discussion est qu'il y a certainement besoin de bibliothèques pour faciliter l'écriture de plugins de stockage

??

sauf pour le binaire c'est a voir

OMI, le cas des valeurs binaires est très différent. C'est une traduction de valeur clé 1:1, comme beaucoup d'autres ( rgbcolor , macaddr , ipaddr , etc), donc un plugin est en fait bien adapté ici. Cependant, comme je l'ai dit, une nouvelle API de plugin qui ne traite qu'une seule clé à la fois pourrait être une amélioration. Mais cela peut facilement être ajouté après la version 1.0 car ce ne serait pas un changement décisif s'il était fait correctement.

le plus -> doit?

Oui, je le vois de la même manière : il est irréaliste que ce changement se produise une fois la version 1.0 sortie (le but de la version 1.0 est de geler de telles décisions afin que d'autres puissent s'y fier) ​​et ce serait bien d'avoir de telles améliorations avant . Mais comme je l'ai dit : nous devons vraiment nous concentrer sur l'accomplissement des tâches essentielles et ne pas perdre notre énergie dans des batailles agréables que nous ne pouvons pas gagner avec notre main-d'œuvre actuelle.