c++ - Lua vs. XML para almacenamiento de datos

(9)

Muchos de nosotros hemos sido adoctrinados en el uso de XML para almacenar datos. Sus beneficios y desventajas son generalmente conocidos, y seguramente no quiero discutirlos aquí. Sin embargo, en el proyecto que estoy escribiendo en C ++, también estoy usando Lua. Estoy muy sorprendido de lo bien que se puede usar Lua para almacenar y manejar datos. Sin embargo, este aspecto de Lua es menos reconocido, al menos en el mundo de la programación de juegos.

Soy consciente de que XML tiene sus ventajas en casos como el envío de datos a través de Internet y en lugares donde entra en juego la seguridad (por ejemplo, utilizando datos descargados de la red o cargando archivos de configuración editables por el usuario) y finalmente en casos donde Los mismos datos están siendo leídos por programas en diferentes idiomas.

Sin embargo, una vez que aprendí lo agradable y fácil que es manejar los datos usando Lua (¡especialmente teniendo que luabind para respaldarte!), Comencé a preguntarme ¿hay alguna razón para usar XML para almacenar datos del juego, si ya usamos Lua?

Blizzard, mientras usa Lua para crear secuencias de comandos de la interfaz de usuario, aún almacena el diseño en XML. ¿Es la razón algo que solo está relacionado con la IU?

¿Cuáles son los inconvenientes de usar Lua como lenguaje de almacenamiento de datos?

¡Gracias por sus respuestas hasta ahora! Me tomaré la libertad de resumir los puntos para futuras referencias.

Desventajas de usar Lua para almacenar datos, en comparación con XML

Seguridad tanto al transferir datos como al almacenarlos, especialmente cuando se reciben datos de una fuente desconocida
Portabilidad y facilidad de acceso a los datos mediante otras herramientas.
Herramientas existentes menos útiles como los validadores de esquemas XML
Menos soporte para analizar los datos
Problemas con referencias circulares.
Menos restrictivo: más difícil de imponer convenciones, uso y diseño adecuados

Beneficios de usar Lua para almacenar datos, en comparación con XML

Uso de un solo idioma tanto para secuencias de comandos como para datos (no se necesitan archivos separados, no se necesitan casos especiales al cargar)
Menos código y dependencias debido al uso de un solo idioma
Más verboso y (posiblemente) más legible para los humanos
Mucho más flexible y extensible (después de todo, es un lenguaje de programación)
Los datos se "ejecutan" y se puede acceder a ellos cuando sea necesario, ya que se encuentra en la máquina virtual
Ocupa menos espacio, especialmente si se compila a bytecode

Si me perdí algo en la primera lista, ¡señálelo!

Es posible que este no sea el tipo de respuesta que esperaba, pero podría ayudarlo a tomar una decisión.

Blizzard (WoW) utiliza XML para definir la interfaz de usuario. Es un poco como XAML en C #, solo que mucho menos potente y la mayoría de los complementos solo usan XML para arrancar el complemento y luego construir la interfaz de usuario en código lua.

También WoW realmente almacena complementos "Variables guardadas" en archivos .lua .

En mi opinión no importa mucho. Elija algo que le guste y que sea fácil de usar para aquellos que van a extender su motor.

Lo bueno de XML es que hay MUCHAS herramientas y códigos ya escritos para probar, escribir y analizar XML, lo que significa que podría ahorrarle algo de tiempo. Por ejemplo, los esquemas XML son muy útiles para validar archivos escritos por el usuario (la seguridad es solo un efecto secundario, lo bueno es que si pasa su esquema, es muy probable que los datos estén 100% seguros y listos para ser conectados a su motor) y hay bastantes validadores ya escritos para que los uses.

Entonces, nuevamente, algunos usuarios tienen miedo de los archivos XML (aunque son muy legibles, quizás demasiado legibles) y preferirían algo "más simple". Si es solo para almacenamiento (no para configuración), en la mayoría de los casos nadie va a editar esos archivos. XML también ocupará más espacio que lua var dump (no debería importar, a menos que tenga muchos datos).

No creo que puedas equivocarte aquí. Blizzard está usando lua para almacenamiento y me gusta bastante cómo funciona.

He hecho algunos proyectos que utilizaron Lua como el idioma de almacenamiento / configuración de datos

El elemento clave en la decisión de usarlo fue "¿Ya estábamos usando Lua en ese proyecto?"

Otra cosa es que es portátil a cualquier lugar donde pueda compilar el intérprete lua. Es igual en todas las plataformas: no hay bibliotecas xml especiales

JSON es una buena alternativa.

La única manera de usar XML en estos días es con code-gen anotado para los serializadores .NET xml o JAXB, por ejemplo).

Lua es una gran victoria para almacenar datos. Conveniente, rápido y fácilmente convertible a otros formatos según sea necesario. (La convertibilidad asume que sus datos se pueden representar en otros formatos, que si se pueden representar en XML, lo serán).

¿Cuáles son los inconvenientes de usar Lua como lenguaje de almacenamiento de datos?

Soy consciente de dos inconvenientes , cuyo significado depende de su aplicación:

Si tiene tablas Lua que contienen referencias circulares, por ejemplo, t1.next == t2 y t2.prev = t1 , entonces el proceso de escritura de sus estructuras Lua en el disco se vuelve tedioso, y el Lua resultante es más difícil de leer que un simple return <list of big expressions here> . (Esto nunca me ha sucedido, y si sus datos se pueden representar en XML, no le sucederá a usted).
Si tiene una gran cantidad de datos, por ejemplo, si está escribiendo un índice invertido de todo el manual de Inform 7, puede contravenir los límites de Lua en el número de constantes distintas que pueden aparecer en un bloque. Luego, tiene que dividir las cosas en varios bloques o funciones, o recurrir a otras soluciones. Este problema me ha mordido, y es un gran dolor en el culo. Me gustaría escribir una solución general, pero no estoy 100% sólido. Entiendo las restricciones y todavía no las he abordado.
Si sus datos tienen menos de 100,000 literales numéricos y de cadena, no tiene que preocuparse por este problema.

Normalmente me mantengo alejado de XML, principalmente debido a su verbosidad. La mayoría de las veces utilizo CSV o SQLite para el almacenamiento de datos. Uso lenguajes de scripting como Lua, Python o Scheme para proporcionar una interfaz para que el usuario extienda el software.

Recuerda que el Lua VM y el lenguaje son muy flexibles. Puede usar entornos de funciones para implementar cualquier forma de seguridad que desee, y luego usar la política para evitar ejecutar código "malicioso". Simplemente elimine TODO el entorno con el que carga () sus datos y lo único peligroso que pueden hacer sus "datos" es ejecutar un bucle y grabar la CPU.

La otra cosa que debe recordar es que siempre puede convertir una tabla Lua en XML y viceversa, aunque la asignación de elementos y atributos en tablas Lua dará como resultado algunos patrones extraños en las tablas.

Si los scripts de lua son accesibles para el usuario, entonces debe aplicarse el subconjunto de lua que está utilizando para la especificación de datos, de lo contrario, lo que tiene no es solo un lenguaje de datos, sino un agujero de seguridad. El problema de imponer tal subconjunto no es trivial.

¿Eres consciente de JSON? Eso podría ser más el tipo de cosa que estás buscando.

Hay dos implementaciones aquí: http://json.luaforge.net/

y aquí http://www.chipmunkav.com/downloads/Json.lua

si json no es lo suficientemente poderoso, otra opción es YAML, un superconjunto de JSON, aunque no podría decirte si hay implementaciones decentes en Lua.

Si no es seguridad, entonces considere la disciplina. Si el rango completo de LUA está disponible en un archivo de datos, queda la posibilidad de agregar lógica o comportamiento a su archivo de datos. Tener estas entidades que son tanto datos como comportamiento puede complicar la gestión de un proyecto grande: supongamos, por ejemplo, que construyó un motor de juego y un juego completo. Ahora desea eliminar todo el contenido específico, reutilizar el motor del juego para crear un nuevo juego. Si el contenido / los datos se dividen de forma segura a partir del comportamiento, esto es bastante sencillo. Si en un momento de debilidad decidiste un día que la mejor solución a un problema es almacenar una función como datos, entonces las cosas se ponen un poco raras.

Es posible que pueda imponer dicha disciplina dentro de su equipo, pero si existe la posibilidad de que un usuario la aproveche. Luego, en el camino, decide cambiar el formato de datos, y esas extensiones de usuario no son portátiles porque incluyen lua que no es datos.

Tales entidades son más difíciles de manipular programáticamente en una escala masiva.

Y hay todos los otros problemas que surgen de preocupaciones que no se separan adecuadamente. Si permite que sus datos y código se mezclen, es probable que todo siga funcionando, pero cuanto más se enreden las cosas, más difícil será razonar.

Yo diría que la mayor desventaja es que es más difícil para otras herramientas manipular esos datos. Si almacena los datos directamente en Lua, debe escribir un analizador de Lua para manipular esos datos automáticamente, mientras que cada entorno tiene analizadores y generadores XML. Esto no es un problema solo para herramientas en otros idiomas; Si desea escribir una GUI para editar su configuración, ¿tiene herramientas que puedan analizar, modificar y escribir los datos de configuración de una manera que no afecte la fusión en su sistema de control de versiones? Eso puede ser importante para grandes proyectos con muchas personas que pueden estar editando la configuración al mismo tiempo.

Dicho esto, esta misma idea es lo que llevó a JSON , que es un subconjunto de JavaScript utilizado como formato de datos. Pero hay muchas herramientas actualmente que soportan JSON, y probablemente no muchas que soportan la sintaxis de Lua.

Otro problema que surge ocasionalmente cuando su código es su configuración es que las personas comienzan a escribir código para generar la configuración o para agregar abstracciones a su archivo de configuración. Y luego, cualquier usuario que desee personalizar su programa podría terminar confundido, teniendo que aprender cómo programar y un lenguaje de programación completo en lugar de un lenguaje de configuración relativamente simple.