Lua vs. XML pour le stockage de données

Merci pour vos réponses si loin! Je me permets de résumer les points pour référence future.

Inconvénients de l'utilisation de Lua pour stocker des données, par rapport à XML

1. sécurité lors du transfert et du stockage des données, en particulier lors de la réception de données provenant d'une source inconnue
2. portabilité et facilité d'accès aux données par d'autres outils
3. outils existants moins utiles comme le schéma XML les validateurs
4. Moins de soutien pour l'analyse des données
5. Problèmes avec des références circulaires
6. moins restrictif -- plus difficile à appliquer les conventions, l'usage et la conception appropriés

avantages de L'utilisation de Lua pour stocker des données, par rapport à XML

1. utiliser une seule langue pour les scripts et les données (pas besoin de fichiers séparés, pas besoin de cas spéciaux lors du chargement)
2. moins de code et de dépendances à cause de l'utilisation d'une langue unique
3. plus verbeux et (sans doute) plus lisible par les humains
4. beaucoup plus souple et extensible (c'est un langage de programmation, après tout)
5. Données est "exécuté" et peut être consulté en cas de besoin car il se trouve dans la machine virtuelle
6. prend moins d'espace, surtout s'il est compilé en bytecode

si j'ai manqué quelque chose dans la première liste, s'il vous plaît le signaler!

Lua est une victoire majeure pour le stockage de données. Pratique, rapide et facilement adaptable à d'autres formats au besoin. (Convertibilité suppose que vos données sont représentable dans d'autres formats, qui, si elle est représentable en XML, il sera.)

Quels sont les inconvénients d'utiliser Lua comme langage de stockage de données?

je suis au courant de deux inconvénients, dont l'importance dépend de votre application:

• si vous avez des tables Lua qui contiennent des références circulaires, par exemple,t1.next == t2 et t2.prev = t1, alors le processus d'écriture de vos structures Lua sur disque devient fastidieux, et le Lua résultant est plus difficile à lire qu'un simple return <list of big expressions here>. (Cela ne m'est jamais arrivé, et si vos données sont représentables en XML, cela ne vous arrivera pas.)

• Si vous avez un beaucoup de données-par exemple, si vous écrivez un index inversé de L'ensemble du manuel Inform 7-alors vous pouvez courir au-delà des limites de Lua sur le nombre de constantes distinctes qui peuvent apparaître dans un bloc. Vous devez alors diviser les choses en plusieurs blocs ou fonctions, ou recourir à d'autres solutions. Ce problème a mordu moi, et c'est une énorme douleur dans le cul. Je voudrais écrire une solution générale, mais je ne suis pas 100% solide je comprends les contraintes, et je ne l'ai pas encore abordé.

  Si vos données ont moins de 100 000 numérique et la littérature des cordes, vous n'avez pas à vous soucier de ce problème.

si ce n'est pas la sécurité, alors envisagez la discipline. Si la gamme complète de LUA est disponible dans un fichier de données, la possibilité demeure d'ajouter la logique ou le comportement à votre fichier de données. Avoir ces entités qui sont à la fois données et comportement peut compliquer la gestion d'un grand projet: supposons par exemple que vous avez construit un moteur de jeu, et un jeu entier. Maintenant, vous voulez en extraire tout le contenu spécifique, réutiliser le moteur de jeu pour faire un nouveau jeu. Si le contenu / les données sont séparés en toute sécurité de behavior, alors c'est assez simple. Si dans un moment de faiblesse vous avez décidé un jour que la meilleure solution à un problème est de stocker une fonction comme les données, les choses deviennent un peu bizarre.

vous pourriez être en mesure d'imposer une telle discipline au sein de votre équipe, mais de la possibilité est là pour un utilisateur, il va être exploité. Ensuite, plus tard, vous décidez de changer le format de données, et ces extensions d'utilisateurs ne sont pas portables parce qu'ils comprennent lua qui n'est pas des données!

Ces entités sont plus difficiles à manipuler programmatiquement à une échelle massive.

et il y a toutes les autres questions qui viennent de ne pas séparer correctement les préoccupations. Si vous permettez à vos données et code de se mélanger, tout fonctionnera probablement encore, mais plus les choses s'enchevêtrent, plus elles seront difficiles à raisonner.

je dirais que le plus grand inconvénient est qu'il est plus difficile pour d'autres outils pour manipuler ces données. Si vous stockez les données directement dans Lua, alors vous devez écrire un analyseur Lua afin de manipuler ces données automatiquement, alors que chaque environnement a des analyseurs et des générateurs XML. Ce n'est pas un problème seulement pour les outils dans d'autres langues; si vous voulez écrire une interface graphique pour éditer votre configuration, avez-vous des outils qui peuvent analyser, Modifier et écrire les données de configuration d'une manière qui n'affecte pas la fusion dans votre système de contrôle de version? Cela peut être important pour les grands projets avec beaucoup de gens qui peuvent éditer la configuration en même temps.

cela dit, cette même idée est ce qui a conduit à JSON, qui est un sous-ensemble de JavaScript utilisé comme format de données. Mais il y a beaucoup d'outils actuellement qui prennent en charge JSON, et probablement pas beaucoup qui prennent en charge la syntaxe de Lua.

un Autre problème qui arrive de temps en temps quand vous avez votre code votre configuration est que les gens commencent à écrire du code pour générer une configuration, ou pour ajouter des abstractions à votre fichier de configuration. Et puis tout utilisateur qui pourrait vouloir personnaliser votre programme pourrait se retrouver confus, ayant à apprendre comment programmer et un langage de programmation entier plutôt qu'un langage de configuration relativement simple.

si les scripts lua sont accessibles à l'utilisateur, alors le sous-ensemble de lua que vous utilisez pour la spécification des données doit être appliqué, sinon ce que vous avez n'est pas seulement un langage de données, mais un trou de sécurité. Le problème de l'application d'un tel sous-ensemble n'est pas négligeable.

Êtes-vous au courant de json? Qui pourrait être plus le genre de chose que vous êtes après.

il y a deux implémentations ici: http://json.luaforge.net/

et ici http://www.chipmunkav.com/downloads/Json.lua

si json n'est pas assez puissant, une autre option est YAML, un super-ensemble de JSON, bien que je ne puisse pas vous dire s'il y a des implémentations décentes de cela à Lua.

rappelez-vous que la Lua VM et le langage sont très flexibles. Vous pouvez utiliser des environnements de fonction pour mettre en œuvre n'importe quelle forme de sécurité que vous voulez, et puis utiliser la politique pour éviter d'exécuter le code "malicieux". Il suffit d'éliminer tout de l'environnement vous loadstring () vos données avec et la seule chose dangereuse que vos "données" peuvent faire est d'exécuter une boucle et de graver CPU.

l'autre chose à se rappeler est que vous pouvez toujours convertir une table Lua en XML et vice-versa, bien que le mappage des éléments et des attributs sur les tables Lua résultera en quelques modèles bizarres dans les tables.

j'ai fait quelques projets qui ont utilisé Lua comme langage de stockage de données/Configuration

l'élément clé dans la décision de l'utiliser était "avons-nous déjà utilisé Lua sur ce projet?"

une Autre chose est que son portable n'importe où, vous pouvez compiler l'interpréteur lua. C'est la même sur toutes les plateformes - il n'y a pas bibliothèques xml

JSON est une bonne alternative.

la seule façon d'utiliser XML de nos jours est avec le code-gen annoté pour serializers. net xml ou JAXB par exemple).

je me tiens habituellement à L'écart de XML, principalement en raison de sa verbosité. La plupart du temps, J'utilise CSVs ou SQLite pour le stockage de données. J'utilise des langages de script comme Lua, Python ou Scheme pour fournir une interface à l'utilisateur pour étendre le logiciel.