Discusión:ORCO (especificación)
De WikiCAAD, la enciclopedia aventurera.
m |
|||
| (4 ediciones intermedias no se muestran.) | |||
| Línea 4: | Línea 4: | ||
--[[Mel Hython]] 07:17 14 ene 2008 (EST) | --[[Mel Hython]] 07:17 14 ene 2008 (EST) | ||
| + | |||
| + | |||
| + | buena idea esto de bajarlo al wiki. | ||
| + | Yo no dispongo de tiempo ahora, por lo que creo que me hago a un lado, hasta nuevo aviso. | ||
| + | |||
| + | te apoyo desde las sombras Al-! | ||
| + | --[[Aventurero:Sarganar|sarganar]] 12:57 14 ene 2008 (EST) | ||
| + | |||
| + | Hola, | ||
| + | |||
| + | La verdad es que desde el artículo de SPAC, le he estado dando un par de vueltas al tema... | ||
| + | |||
| + | En vez de orientarme a xml, lo he hecho a base de datos (¿deformación profesional?) El modelo que he diseñado (con aportaciones de ORCO) es el siguiente: | ||
| + | |||
| + | [[Imagen:ModeloORCO.png]] | ||
| + | |||
| + | Sobre los requisitos tecnicos, también he avanzado, pero todavía no hay nada más que mostrar que las intenciones: | ||
| + | Para la parte cliente: | ||
| + | ------------------------ | ||
| + | # Python como lenguaje | ||
| + | # SQLite3 como SGBD | ||
| + | # SQLObject como librería ORM | ||
| + | # wxWidgets como toolkit gráfico (el único que en windows parece "nativo") | ||
| + | |||
| + | Para la parte servidor: | ||
| + | ----------------------- | ||
| + | # PHP como frontend para añadir nuevas aventuras, con instrucciones, imagenes, etc... | ||
| + | # Mysql como SGBD | ||
| + | |||
| + | |||
| + | Y para comunicarse ambos, webservices implementados en XML-RPC | ||
| + | |||
| + | |||
| + | Buff... mucho vaporware para tan poco texto :) | ||
| + | |||
| + | |||
| + | --[[Aventurero:Mapache|Mapache]] 05:27 17 ene 2008 (EST) | ||
| + | |||
| + | |||
| + | |||
| + | Bueno, veo que el modelo está currado... pero no sé, yo lo veo un poco complejo. El XML tiene la ventaja de que especificas todo lo que hay que especificar de manera muy simple (la especificación esa que hice yo es muy informal porque es sólo un borrador, pero una versión definitiva, formal y bien especificada no ocuparía mucho más). Y luego que no tiene ningún requisito, no hace falta ni base de datos ni nada, simplemente un programa que pueda hacer peticiones HTTP y que pueda parsear XML. Con lo cual podrían surgir todo tipo de clientes, desde los más complejos hasta los más sencillos que sean una aplicación de línea de comando que ocupe 100 K. Y en la parte de servidor, lo mismo: sólo hace falta un servidor http y luego alguien que edite, posiblemente a mano, un fichero XML (si después se quiere hacer una aplicación server-side de configuración, se puede, pero no es un requisito para que la cosa pueda actualizarse de manera relativamente fácil). | ||
| + | |||
| + | Ahora bien, si tu modelo lo vas a implementar y vamos a tener un cliente y servidor funcionales, por mí perfecto, eh :D | ||
| + | |||
| + | Lo que sí echo en falta es el concepto intermedio de formato entre aventura e intérprete, que estrictamente no hace falta, pero creo que puede hacer los datos más fáciles de manejar y actualizar (no tienes por qué asociar cada aventura glulx al winglulxe, al glulx de linux y al gargoyle, las asocias a formato glulx, y ese formato ya sabe qué intérpretes lo abren). | ||
| + | |||
| + | --[[Aventurero:Al-Khwarizmi|Al-Khwarizmi]] 08:28 17 ene 2008 (EST) | ||
Última versión de 13:31 17 ene 2008
- Pon un anuncio en los foros del CAAD.
- Detalla más la arquitectura y requisitos del cliente y del servidor.
- Tal vez 'juegos' no sea un concepto lo bastante general para esto.
--Mel Hython 07:17 14 ene 2008 (EST)
buena idea esto de bajarlo al wiki.
Yo no dispongo de tiempo ahora, por lo que creo que me hago a un lado, hasta nuevo aviso.
te apoyo desde las sombras Al-! --sarganar 12:57 14 ene 2008 (EST)
Hola,
La verdad es que desde el artículo de SPAC, le he estado dando un par de vueltas al tema...
En vez de orientarme a xml, lo he hecho a base de datos (¿deformación profesional?) El modelo que he diseñado (con aportaciones de ORCO) es el siguiente:
Sobre los requisitos tecnicos, también he avanzado, pero todavía no hay nada más que mostrar que las intenciones: Para la parte cliente:
- Python como lenguaje
- SQLite3 como SGBD
- SQLObject como librería ORM
- wxWidgets como toolkit gráfico (el único que en windows parece "nativo")
Para la parte servidor:
- PHP como frontend para añadir nuevas aventuras, con instrucciones, imagenes, etc...
- Mysql como SGBD
Y para comunicarse ambos, webservices implementados en XML-RPC
Buff... mucho vaporware para tan poco texto :)
--Mapache 05:27 17 ene 2008 (EST)
Bueno, veo que el modelo está currado... pero no sé, yo lo veo un poco complejo. El XML tiene la ventaja de que especificas todo lo que hay que especificar de manera muy simple (la especificación esa que hice yo es muy informal porque es sólo un borrador, pero una versión definitiva, formal y bien especificada no ocuparía mucho más). Y luego que no tiene ningún requisito, no hace falta ni base de datos ni nada, simplemente un programa que pueda hacer peticiones HTTP y que pueda parsear XML. Con lo cual podrían surgir todo tipo de clientes, desde los más complejos hasta los más sencillos que sean una aplicación de línea de comando que ocupe 100 K. Y en la parte de servidor, lo mismo: sólo hace falta un servidor http y luego alguien que edite, posiblemente a mano, un fichero XML (si después se quiere hacer una aplicación server-side de configuración, se puede, pero no es un requisito para que la cosa pueda actualizarse de manera relativamente fácil).
Ahora bien, si tu modelo lo vas a implementar y vamos a tener un cliente y servidor funcionales, por mí perfecto, eh :D
Lo que sí echo en falta es el concepto intermedio de formato entre aventura e intérprete, que estrictamente no hace falta, pero creo que puede hacer los datos más fáciles de manejar y actualizar (no tienes por qué asociar cada aventura glulx al winglulxe, al glulx de linux y al gargoyle, las asocias a formato glulx, y ese formato ya sabe qué intérpretes lo abren).
--Al-Khwarizmi 08:28 17 ene 2008 (EST)
