Al-Khwarizmi escribió:
En lo de generar especificaciones ORCO automáticamente desde el portal estoy de acuerdo, sería lo ideal.
Eso es muy fácil... consulta a la bd y que devuelva la respuesta en el formato xml que se especifique.
Mi humilde opinión respecto al otro tema...
Me inclino más hacia el lado de Johan... Creo que cualquier cosa dependiente de la plataforma cliente debería estar en el lado del cliente, y que, al igual que se obliga a que el cliente sepa descomprimir el archivo descargado, que sea él el que sepa cómo ejecutar una aventura en su correspondiente intérprete.
Me explico, el cliente en sí ya será dependiente del S.O. y, si es multiplataforma, al menos puede saber en que S.O. se está ejecutando. Por tanto, toda la info de los xml que no sea para su versión de S.O. le sobra.
Aún así, el cliente puede seguir sirviendo sin mantenimiento, ya que todo esto no tiene por qué estar "hardcodeado" en el código. Puede estar perfectamente parametrizado en ficheros .ini, .cfg o .xml, pero particulares para esa versión del S.O. para el que se ha compilado el cliente.
Que si en WinXP se ejecuta así, que si en Win7 es igual pero con permisos de Administrador, que si en Debian es tal y en Redhat es pascual... Sinceramente, intentar hacer un xml en servidor que englobe todas las posibles configuraciones del usuario cliente me parece inabarcable. Se nos va a escapar algo seguro.
Me parece mucho más sencillo y cómodo para todos crear un fichero de configuración para el cliente, sólo con la información que le corresponde... Y si un día aparece una nueva versión de un intérprete para win7, o un intérprete nuevo para MacOs o se añade un package en el repositorio de tal distribución de Linux, pues solo es añadir la entrada correspondiente al fichero de configuración y arreglado (que incluso se podría hacer desde un formulario en el propio cliente).
Así, el xml a mantener sería el listado de aventuras... el orco-games está bien, aunque echo en falta información bibliográfica, para poder ver autor, sinopsis, género, etc, en la aplicación cliente. Incluso me sobraría la parte de <install>, si el cliente se hace bien...
Razono...
Entendiendo que $GAMES y $DOWNLOADS son parámetros de configuración del cliente (que tendrán un valor por defecto durante la instalación, pero que pueden ser cambiados por el usuario en cualquier momento), el cliente ya sabe dónde se va a descargar un fichero y donde lo tiene que dejar para jugarlo (el subdirectorio podría ser automáticamente el atributo title más el atributo version del tag game), por tanto en el momento de borrar también lo sabe...
El extract también sería redundante, ya que el cliente sabe el directorio origen, el destino y el formato descargado (o bien por la extensión o bien añadiendo un atributo compress="zip|rar|tar|gz|...|no" en el tag con la url de descarga), por tanto, conoce toda la información necesaria sin necesidad de especificarla en el xml (que podría ser errónea o no válida para todos los S.O, no sé, se me ocurren los separadores de ruta, el case-sensitive o lo que fuera).
Pues eso, que el xml se limitaría a la lista de de juegos, con su correspondiente información para que la vea el usuario, y la información para el cliente sería la url de descarga, el intérprete para el que está programada, el "ejecutable" de la aventura y el formato de compresión del fichero descargado.
Seguramente me dejo muchas cosas que tenía pensado o que comenté ayer por el irc, pero básicamente lo que pretendía decir es que todo lo dependiente de la plataforma donde se ejecute el cliente, donde mejor está es en el cliente.
Si en una recreación del xml, hay un error en la instrucción para ejecutar gargoyle porque ha salido nueva versión, ya ha jodido a todo el mundo, que no va a poder jugar a ninguna aventura con gargoyle.
Sin embargo, si toda esta lógica está en configuración del cliente, no fastidiamos a nadie...
Además que cada cliente implementaría esta configuración como le venga en gana al creador del mismo... en bd, en ficheros externos, en parámetros de aplicación, en variables de entorno, en definitiva, en lo que sea o más fácil le parezca...
Pos eso...