CAAD

Hombre, tienes que reconocer que en esos mensajes era la impresión que daba (o al menos a mí me la dio); porque yo estaba diciendo repetidas veces que el autor no iba a tener que escribir el XML y tú respondías partiendo de que el autor iba a tener que escribir el XML.

Ahora has explicado mejor tu postura; pero te digo la lógica que sigo yo para pensar que poner esa información en el XML (o JSON o lo que sea, efectivamente usar uno u otro formato no es lo más importante; aunque a mí me gusta XML porque se carga los problemas de encodings al especificar el encoding explícitamente en la primera línea):

- Instalar y ejecutar intérpretes y aventuras en distintos sistemas operativos tiene una lógica de cierta complejidad. Por ejemplo, para una aventura Glulx tienes que saber bajarte un intérprete Glulx adecuado para tu sistema operativo, copiarlo a alguna parte, bajarte la aventura, copiarla a alguna parte (sin conflictos de nombrado con otras aventuras, si puede ser), y ejecutar la aventura con el intérprete. Además, los requisitos pueden ser algo más complejos que ésos: puede haber aventuras que incluyan ficheros externos. Puede haber aventuras que requieran varias herramientas o requisitos muy distintos para jugarse (una aventura en Visual Sintac en Windows requerirá el Visual Sintac, en Linux requerirá el Wine y el Visual Sintac, etc.)

- Además, los requisitos muchas veces no se reducen a algo tan simple como "la aventura es del formato X así que ejecuto el intérprete Y": puede haber aventuras específicas que vayan mejor con un intérprete de Glulx que con otro (caso de las aventuras en Superglús que no funcionan en Git y se abren con Winglulxe, o de alguna aventura multimedia que se ve mejor en algún intérprete concreto).

- Para que todas estas cosas se hagan con un click, sin intervención del usuario, está claro que toda esta lógica tiene que estar en algún sitio. Aquí es donde discrepamos: ¿dónde debería estar? Tú opinas que (al menos en buena parte) en la aplicación cliente. Yo opino que fuera de la aplicación, y por lo tanto definida como datos externos (en este caso representados en XML).

¿Por qué pienso esto? Pues porque en cuanto metes algo de esa lógica en la aplicación cliente, estás vendido. Porque esa lógica puede cambiar (y bastante) con el tiempo. Pueden aparecer nuevos formatos. Podemos querer ejecutar aventuras de formatos que no se previeron cuando se programó la aplicación. Pueden aparecer nuevas versiones de intérpretes, que tal vez se ejecuten de distinta manera. Pueden aparecer nuevas versiones de sistemas operativos que impongan nuevos requisitos, por ejemplo que para ejecutar algo necesitemos emulador cuando antes no hacía falta (como pasó con las aventuras para DOS en Windows). Pueden aparecer nuevos bugs en intérpretes que impongan nuevos requisitos, como el que hacía que las aventuras de Superglús no se ejecutaran bien en git. Y un largo etcétera.

Si la lógica de cómo ejecutar las aventuras la metes en la aplicación, querría decir que cada vez que estuviésemos en uno de esos casos, habría que sacar una nueva versión de la aplicación. Eso significa que la aplicación necesitaría tener mantenimiento continuado en el tiempo, y eso ni va a suceder, ni es deseable que sea necesario que suceda.

Por eso la idea de ORCO es que toda la lógica sobre cómo instalar aventuras esté en una fuente de datos en un formato estándar (en este caso, XML). De esta manera, si pasa cualquiera de esas cosas que hacen que haya que añadir nuevas formas de ejecutar aventuras o cambiar las existentes, no hay que hacer nada en la aplicación. Ésta, en cuanto fuera estable, podría seguir funcionando durante años, por lo menos mientras funcionen las capas sobre las que esté hecha (C++ y Qt o lo que sea).

Dentro de esa idea de que no haya lógica específica de instalación en la aplicación (que sólo haya suposiciones comunes y universales como "existe un directorio que llamaremos el directorio de juegos", "podemos escribir un fichero a un directorio" o "sabemos extraer un zip"), lógicamente los detalles de cómo expresar esa lógica (si existe el "delete" o no, o cosas así) son sólo un borrador que se puede, y seguramente se debe, discutir. Pero si empiezas a meter lógica específica de instalación en la aplicación, entonces sí que ya lo que tendrías no sería ORCO, sería otra cosa mucho menos flexible... y condenada a la muerte, como lo estuvo puertAventura, que a mí me encantaba pero ahora no lo tenemos porque cometió el error de requerir mantenimiento.

¿El hecho de que los datos estén fuera de la aplicación implica que los tenga que escribir el autor? Pues, como digo, no. La idea sería que todo lo que es repetitivo se generara. No veo por qué nadie iba a tener que teclear la rutina de instalación para las aventuras Z si es siempre igual. Se puede hacer un formulario (en aplicación local o web) que si una aventura es Z genere eso, y ya está. Es algo que, a diferencia de mantener la aplicación cliente, es totalmente trivial y está al alcance de mucha gente en el CAAD.

Si aun así tenéis miedo de que los autores tengan que terminar tecleando a mano esas especificaciones, siempre se podría añadir a ORCO un soporte de "subrutinas" para que se pueda definir en el XML una subrutina "instalarZLinux" y que luego todas las aventuras Z puedan llamar a "instalarZLinux" con un solo elemento XML. Esto es algo que pensé en su momento, y no lo incluí por una razón muy sencilla: complica la vida a los implementadores del protocolo, porque es una cosa más que tienen que soportar, y realmente no simplifica la vida a nadie salvo a quienes editen el XML a mano, cosa que normalmente para tareas repetitivas no se debería hacer.

Si realmente queréis que el XML sea más fácil de editar a mano, se podría añadir ese soporte complicándole la vida a minidu un poco... pero que conste que quien quiere que los autores tecleen a mano no soy yo. Por mí quedaría como está ahora, muy fácil de procesar por los clientes y muy fácil de generar con una sencilla aplicación auxiliar.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Pero Al-K es que es falso que puertAventura estuviese condenada a la muerte, por ser una aplicación compleja con mucha lógica en su interior. Desde mi punto de vista la forma de asegurar la supervivencia no es crear un fichero de configuración tan detallado sino hacer que la aplicación sea OpenSource y ése es el caso de puertAventura:

http://sourceforge.net/apps/trac/puertaventura/

Cuando Mapache abandonó, pensé en hacerme cargo del proyecto pero no tenía ni idea de Python (ni ganas) así que no me podía ni plantear hacerlo. Ahora llevo (lamentablemente) un año programando en Python, así que no hace mucho me plantee rescatar el proyecto y relanzarlo... y entonces, descubrí en la primera exploración que web-aventura había desaparecido del servidor!

Sinceramente no lo entendía, pero supuse que es que puertAventura no parecía un proyecto interesante en la comunidad, así que escribí esta entrada en mi blog:

http://pacificaciones.blogspot.com/2011 ... nidad.html

Entre otras cosas como 'globo sonda', a ver qué reacción provocaba. La primera reacción me dejó bastante perplejo:



'¿Ein?', pensé, '¿Qué tiene que ver el uso de XML o de base de datos para que el autor fuese o no necesario para mantenerlo?'. Luego vi con alegría que se suscitó bastantes respuestas, incluyendo una del propio mapache, que incluso alguno casi se atreviesen a retomar el proyecto... pero no pasó nada más.

Lo del mantenimiento continuo efectivamente es cierto, pero al mover las instrucciones de cómo tratar los diferentes formatos y cuáles son los intérpretes adecuados, de la aplicación a los fichero de configuración lo que se consigue es mover el trabajo de mantenimiento desde un punto 'central' -la aplicación, que podría ser mantenida colectivamente- a todas y cada una de las obras, y ocurrirían las siguientes cosas:

- Algunos autores no se preocuparían de hacer la ficha --> no aparecerían en la herramienta.
- Más probable, muchos autores, yo incluido, se equivocarían en hacer la ficha --> no aparecerían en la herramienta.
- Los autores que dejan el mundillo dejan de mantener su ficha --> dejan de funcionar sus obras en la herramienta.
etc...

En cualquier caso me parece bien que una herramienta de este estilo exista, y no me parece tan mal que se usen especificadores ORCO para que la aplicación pueda ejecutar las obras, pero en ese caso me parece fundamental que cualquier cosa que se suba como ficha del CAAD de aventuras tenga su 'orco' automáticamente generado y además que la herramienta se actualice desde el portal del CAAD usando esos orcos.

Pues en el fondo tú mismo te estás respondiendo, poniendo ejemplos a los argumentos que he dado. ¿Por qué ahora no funciona puertAventura? Porque está diseñado de una manera que requiere mantenimiento, y ese mantenimiento no se ha producido. Requiere una aplicación web en particular con una base de datos con un esquema en particular (mucho más complicada de montar que un fichero XML). Desaparecida esa aplicación web y sin quien la resucite y la mantenga, y con la aplicación cliente también sin mantenimiento, puertAventura no funciona.

¿Sería sencillo volver a darle ese mantenimiento? Pues tú mismo te respondes también. No es trivial, porque hace falta alguien que esté familiarizado con la tecnología correspondiente (Python en el caso de puertAventura, C++ y Qt en el caso del sistema de minidu), y que tenga el tiempo y las ganas de hacerlo. Y si encima hay una parte de la aplicación en el servidor, más difícil todavía. Con los cuatro gatos que somos, no es realista pensar que esas condiciones se van a dar continuamente. De hecho, ya tenemos el ejemplo de que no se han dado.

Como dije en el quote que has pegado, yo ya advertí de todo eso antes de que sucediera. Ahora lo que propones es que tropecemos de nuevo en la misma piedra.

Con la arquitectura de ORCO, una vez hecho el cliente no necesitaríamos ni a nadie que supiese Python o C++, ni ninguna aplicación web, ni un servidor con base de datos, ni nada. Sólo alguna aplicación muy sencilla para generar las fichas en XML, y en el caso de que en algún momento esa aplicación dejase de mantenerse las consecuencias serían que las fichas de algún formato de aventuras/intérprete nuevo habría que generarlas a mano. Incómodo, sí, pero mucho peor es lo que sucede si deja de mantenerse la aplicación con la otra arquitectura: que esas aventuras para el intérprete nuevo directamente no se podrían incluir de ninguna manera o, en el peor de los casos (si lo que falla es el servidor) que el sistema se inutiliza por completo, como sucedió con PA.

En lo de generar especificaciones ORCO automáticamente desde el portal estoy de acuerdo, sería lo ideal.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Bueno, sigo avanzando, creo que mañana lo dedicaré a subir el proyecto a google code, para que puedan ir probándolo aunque no es funcional aún.
Tengo algunas dudas/ideas. Ruego me comenten su opinión.
- Juegos sin soporte: Respecto al problema que plantea Johan: Añadir un tipo de juego no soportado por el gestor, será mostrado en la aplicación pero sólo sacará información de donde obtener las instrucciones dónde bajarlo etc.

Yo entiendo la postura de Al-k, cuanta menos lógica tenga el programa y más configurable sea, mejor aguantará el paso del tiempo. Eso no quita que siga siendo complejo, y quizá vaya a tener bugs a patadas, pero mientras funcione sobre una base...

- Dom en memoria: Una cosa es que hago uso intensivo del documento xml de los juegos una vez parseado, lo dejo en memoria todo el tiempo(como objeto Dom), me pregunto si esto puede ser un inconveniente o debería pasarlo a una base de datos(uso una en memoria para la tabla, pero pasar todo el xml a tablas relacionales puede ser pesado).
- Info en html: La descripción del juego creo que podría estar bien incrustarla directamente en el xml como html, nos ahorramos el campo imagen y se pueden poner enlaces. Es como está puesto ahora mismo.
- Extract Xpath: La información también se podría meter dentro de orco como extracciones XPath de documentos en la red, así no habría problema de duplicación de mantenimiento y contenidos... Con Xpath se pueden extraer subdocumentos o nodos de un documento xml como puede ser en este caso uno de la wiki.
- Formatos de compresión: ¿A qué o cuantos formatos de compresión se les ha de dar soporte? ¿Cómo me sugieren que haga esto? Una opción es bajarse una librería multiplataforma, o usar zlib por ejemplo, pero sólo valdrá éste para zips. Otra es usar comandos externos, más cutre pero bueno.

Sobre lo del generador de fichas no se preocupen, supongo que tendré que hacer alguno en lo que trasncurre este proyecto, ya veremos...
Por cierto dddddd no me olvido de tu ofrecimiento, a ver si me encuentras esos códigos para extraer info de la wiki.

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...

_________________
El humor existe para recordarnos que por muy alto que sea el trono en el que uno se siente, todo el mundo usa su culo para sentarse.

Pues yo no veo ningún problema en que el cliente sea multiplataforma. Precisamente las primitivas que he puesto como ejemplo en ORCO están pensadas para que puedan ser todas ellas multiplataforma. Crear un directorio, copiar un fichero o extraer un zip son cosas que por ejemplo en Java es trivial hacer en cualquier plataforma sin ningún problema, y me imagino que en otros lenguajes multiplataforma será igual. ¿Me podrías dar un ejemplo concreto donde crees que podrían dar algún problema? Porque yo no lo veo. Si estuviésemos hablando de acceder a primitivas de aceleración 3D o cosas así, pues sí, ahí es difícil la programación multiplataforma... pero ¿copiar un fichero, extraer un zip o llamar a un programa con unos determinados argumentos? Eso es trivial.

Por cierto, el ejemplo que pones del error al ejecutar Gargoyle no se aplica porque si te fijas en el XML puedes especificar qué versión usar para un sistema operativo dado. Todo eso estaba pensado.

Por otra parte, dices que en el XML se nos va a escapar algo pero luego hablas de meter esa misma información en ficheros de configuración del cliente. No sé por qué va a ser difícil en un XML unificado y estandarizado y fácil en múltiples ficheros de configuración, la verdad. Yo lo veo al revés.

Sigo diciéndote como a Mel, lo que estáis describiendo ya se probó, se llamó puertAventura y el resultado fue que funcionó durante un tiempo y que ahora no funciona en absoluto. Por aquel entonces ya argumenté que eso pasaría; pero es que ahora encima hay datos. No sé por qué empeñarse en seguir ese camino.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Yo no digo que sea un problema... digo que es redundante, ya que esa info la puede sacar la aplicación cliente por sí sola... Si la deduce la aplicación por sí sola, sabemos que siempre la deducirá igual, si no, depende de lo que ponga en el xml, que no siempre puede ser correcto (por cualquier razón... problema de tipeo, 2 directorios iguales, etc)


Puedo acabar con todas las versiones de un mismo intérprete instaladas en mi ordenador... . Lo deseable, digo yo, es que se tenga solo una versión instalada, normalmente la última.


Sencillamente porque cuando alguien saque el front-end para MacOs, que configure como se instalan y ejecutan los intérpretes existentes para MacOs, idem Android, Windows Phone o cualquier otro.
Lo único que debe mirar es que la especificación vigente del protocolo ORCO define tal y cual entrada para los intérpretes, y es la que debe definir en sus configuraciones.
Y ya digo que sin obligar al programador a que sea un XML. El que hace la herramienta que lo haga como más fácil le resulte.


No, no es lo mismo. El repositorio de aventuras que yo digo es el mismo que tu dices para ORCO. Y el resto es configuración del cliente. Ojo, que digo configuración, no digo ni recompilaciones, mantenimiento ni nada parecido. Simplemente configuración. Y la manera de configurar que la establezca el programador como mejor le parezca en su herramienta, con formularios, con asistentes, con una herramienta externa...
¿Por qué si yo uso la herramienta en un iPad me tiene que dejar de funcionar porque el cliente se me ha bajado un xml corrupto porque hay una versión nueva de winfrotz que ni me va ni me viene?

_________________
El humor existe para recordarnos que por muy alto que sea el trono en el que uno se siente, todo el mundo usa su culo para sentarse.

La información de formato que aparece en el XML de ORCO sólo aparece una vez, y no se va a estar actualizando todos los días. No veo por qué corregir posibles errores en ella va a ser más difícil que corregirlos en el cliente.


Ya, pero puedes definir un formato Glulx que se abra con el intérprete de Glulx, y un formato GlulxLegacy si tienes alguna aventura que da error con ese intérprete, un formato WinGlulxe si sólo se abre con WinGlulxe en Windows, etc.

O sea, no digo que haya que instalar varias versiones como norma general, pero el protocolo es flexible a ese respecto. Y delegando en el cliente, es más difícil proporcionar esa flexibilidad.


Ya, pero ahí volvemos al mantenimiento. Esa persona que hizo el front-end para MacOS, va a estar manteniéndolo unos meses y no va a volver. Y cuando suceda eso y pase un tiempo, todo su trabajo no valdrá para nada. Yo estaré a favor de eso cuando seamos miles y la comunidad sea tan activa que los clientes se puedan mantener indefinidamente, pero eso no va a pasar.



Ahí te doy la razón en que no es exactamente lo mismo, porque puertAventura también tenía el inconveniente de requerir una aplicación web en el servidor, mientras que en este caso sólo tendrías XML sobre un servidor HTTP en el servidor, así que tendrías al menos parte de la flexibilidad de ORCO; aunque renunciarías a otra parte.

Sobre lo del XML corrupto, mira que es difícil crear un XML corrupto, si la mayoría de los editores hoy en día ni te dejan hacer eso

En todo caso, el protocolo contempla que el cliente pueda tener información local y no actualizarla de ninguna web, o actualizar sólo bajo demanda del usuario. Y aunque se actualice automáticamente, lo lógico es que tenga una copia local de la información del XML. Obviamente si el cliente se baja una lista corrupta y está bien programado, lo lógico sería que lo detectara y usara la lista anterior.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Yo creo que dado que tu cliente es para PC, y no para móviles, no pasa nada por consumir un poco de RAM guardando el XML. Además, más recursos aún va a consumir usar una base de datos relacional completa, ¿no? Esas bestias no suelen ser ligeras.


Yo empezaría con el zip, que es el formato en el que están comprimidas la mayoría de las aventuras en el servidor del CAAD y se puede descomprimir en todas las plataformas (al menos en java se puede, así que imagino que en C++ también). Y más tarde, cuando funcionara bien la aplicación y no hubiese otras cosas más importantes que añadir, me plantearía opcionalmente incluir algún otro. Soportar varios formatos de compresión estaría bien pero no me parece muy importante, dado que de mal a mal la gente que cuelgue aventuras siempre podrá adaptarse y usar zip.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

No nos entedemos...
Digo que información como esta:

es redundante, ya que el cliente la averigua de su configuración (entiendo, como dije antes, que GAMES y DOWNLOADS son parámetros en la instalación del cliente) y el resto se saca de otros tags del propio xml... por tanto, el cliente ya sabe qué directorio borrar, qué método para descomprimir, dónde dejar la aventura, dónde está el fichero descargado, etc...


No, eso que decía de consultar la especificación actual de ORCO era solo al crear un nuevo intérprete... Cuando aparezca Winglulxe2013 y quiera jugar a una aventura que requiere Winglulxe2013, mi front-end me dirá que no sabe como ejecutar esa aventura. Entonces yo, no quien hizo el front-end, iré a Herramientas -> Opciones -> Configuración Intérpretes y rellenaré los campos necesarios para añadir Winglulxe2013 a mi front-end. O simplemente porque quiero que todas las aventuras glulx se me ejecuten en Git porque me cae mal winglulxe, por ejemplo. O porque he encontrado un plugin para firefox que me ejecuta código z...

_________________
El humor existe para recordarnos que por muy alto que sea el trono en el que uno se siente, todo el mundo usa su culo para sentarse.

Hombre, eso está bien como opción, lo que pasa es que si queremos que el front-end sirva para novatos, siempre va a ser mejor que pueda descubrir automáticamente (bajándose el XML) que existe el Winglulxe2013.

Configuraciones como la que tú dices realmente son posibles con el protocolo tal como está:

"la elección de qué está en el cliente y qué está en el servidor corresponde a cada cliente o front-end que se implemente. Una buena solución es comenzar con plataformas y formatos en el cliente, bajarse las aventuras, tener la lista de aventuras cacheada en el cliente pero actualizarla cada vez que se ejecute con el servidor si éste está disponible y el cliente está conectado a internet, y por último actualizar la lista de formatos y plataformas llamando al servidor sólo si se encuentra en la lista de aventuras alguna referencia a una plataforma que el cliente no conoce"

Se podría hacer un cliente que diera prioridad a lo que configures tú en el propio cliente sobre lo que diga el XML. Yo no tengo nada en contra de que los clientes tomen iniciativas, lo que sí que quiero es que haya al menos un "fallback" para que si el cliente no puede tomar la iniciativa porque se ha quedado viejo, el XML pueda decirle qué hacer.

De hecho, se podría implementar un cliente que si está convencido de que conoce el formato de la aventura (format name=...), pasara olímpicamente de todas las instrucciones de instalación del XML y tomara sus propias decisiones. Nadie dice que toda la información que aparece en el XML deba usarse necesariamente, la información se provee para poder implementar clientes y luego cada cliente hará con ella lo que prefiera. Pero creo que es importante exigir que el cliente "de referencia" tenga la capacidad de interpretar las instrucciones de instalación, para no tener que cambiar nada en él si salen formatos nuevos.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

A mi me gusta ORCO en general como se ha definido, aunque por supuesto hay que pulir cosas y hacer la especificación más formal, para ello es minidu quien nos puede dar datos de primera mano. Coincido en que en última instancia el cliente puede tener cierta libertad, pero sería deseable que, salvo indicación en contra, tomara los datos de los intérpretes del XML que tiene más garantías de estar actualizado que cualquier otra cosa.

Lo que sí haría yo es añadir un atributo para el formato de compresión:
que puede parecer redundante pero nada garantiza que el nombre del fichero tenga que ser .zip.

Además con esto se podría ir un poco más allá y definir una sección <orco-compression> donde se englobarían los pasos de descompresión (mkdir, extract, etc.) que posiblemente sean siempre los mismos para cada formato de compresión.

No sé quién será ese Mel, pero yo tengo instalado puertAventura y creo que funciona.. a ver... lo arranco y sí... se abre... a ver... pillo una aventura viejuna de spectrum y... vaya se instala y funciona... veamos ahora una moderna, del 2010, de un tipo raro llamado Incanus... a ver instala y... si se ejecuta.

Pues sí, parece que sí que funciona bastante bien... ah, pero espera... que no se puede actualizar porque no hay web que le de los datos, cachis... será por eso que no funciona 'en absoluto'.

Si no me equivoco, te funciona porque ya lo tenías instalado, y por lo tanto tiene guardadas las aventuras en local de la última vez que se conectó a la web. Pero si lo instalaras ahora, lo primero que intentaría hacer es ir a la web para descargar la información de las aventuras, y por lo tanto no funcionaría en absoluto. Digo lo de "si no me equivoco" porque no puedo comprobarlo ya que parece que todos los enlaces están rotos, la aplicación ya no se puede bajar; pero estoy casi seguro de que era así.

No creo que eso se pueda considerar funcionar.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Ya no me acuerdo, sinceramente, creo recordar que venía precargada con una extensa base de datos de fichas de aventuras... lo comprobaría, pero el enlace de descarga apunta al portal del caad y me dice que no tengo permisos para descargármela. De nuevo, este problema de descarga no es de la herramienta ni del sourceforge, sino porque se ha quitado todo soporte a la herramienta en el portal del CAAD.