CAAD

No hay ningún motivo por el que no se pueda sincronizar la información común (título, autor, etc.), otra cosa es que alguien programe los scripts pertinentes para hacer eso. Vuelvo a decir que ORCO simplemente es un formato y un protocolo, y no dice nada de cómo se tiene que generar el XML. Éste se podría generar con formularios, con una web, con scripts que se bajen datos de la wiki... eso ya depende de lo que queramos currarnos.

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

Aunque el XML ya sea cosa del pasado (viva JSON!), lo que me preocupa no es eso, sino fragmentos como estos:



¿En serio? ¿Realmente ves necesario tener que describir cómo se borrar el directorio de instalación, como crearlo, cómo extraerlo, cómo... todo?

En puertAventura sólo tenías que dar el formato, la URL y en caso de que fuese un fichero comprimido con más cosas indicar en qué parte de ese fichero está 'la aventura' -en el caso de que fuese un .z5,.z8 o un .sna o similar, ni eso-. El resto era información de blibiografía.

Yo es que a estas alturas no me veo escribiendo un makefile, la verdad, y no entiendo porqué no se puede reducir a simplemente algo como:

<url>http://www.caad.es/descargas/archipielago.zip<url>
<format>z5:islas.z5</format>

El intérprete (como hacía el puertAventura) con el formato y la url básicamente ya puede localizar lo que debe 'ejecutar', no veo la necesidad de explicitar lo de los directorios y demás. Se trata de un descriptor de aventuras, no de un fichero de un instalador.

El motivo de que no lo haya reducido a eso es que tal como está, es mucho más flexible y genérico.

Con un sistema como el que tú dices, el gestor tiene que conocer internamente los formatos que maneja, y tienen que ser una lista cerrada. Si alguien saca una aventura hecha con un intérprete muy poco conocido, o si alguien saca un intérprete nuevo, el sistema no la soportará hasta que alguien lo actualice. Si sale un nuevo intérprete Glulx con más funcionalidad, el sistema tampoco abrirá las aventuras con él hasta que alguien lo actualice. Cosa que, como hemos visto con puertAventura, puede no suceder nunca si el mantenedor del sistema se cansa.

Tal como está pensado ORCO, sin embargo, quien implemente el cliente sólo tiene que implementar esos comandos genéricos como deldir, extract, etc. y una vez que el cliente funcione, no necesitará más mantenimiento. Si salen intérpretes nuevos, no hay problema, se puede definir en el XML cómo se ejecuta una aventura en ellos. Incluso si alguien quisiera usar ORCO para algo que ni siquiera fuesen aventuras, podría también.

El coste que apuntas de "tener que hacer un makefile" no existe, porque vuelvo a repetir una vez más que la idea del XML de ORCO no es teclearlo a mano, sino generarlo. Si todas las instrucciones de instalación de las aventuras Z son iguales, pues se hace que el programilla las genere cuando le digas que una aventura es Z. Coste cero. Con el valor añadido de que en el caso de que el formato de una aventura no esté registrado en el programa, y a alguien le interese añadirla, podrá introducir la información a mano.

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

A los implementadores: OJO, yo restringiría esos comandos que manejan el sistema de archivos a trabajar encerrados bajo un directorio concreto, que no exista ni la más remota posibilidad de modificar otros ficheros ajenos. A simple vista parece algo sencillo, pero muchos problemas de seguridad aparecen por agujeros de este tipo (y no es suficiente con evitar el uso de '..' y otras medidas básicas).

0.02

Sí, como es lógico es necesario tener en cuenta esas cosas (y si dicho directorio es configurable, mejor que mejor).

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

Pero es que no hay más remedio. Me explico, más abajo...



Eso es utopía, porque en la definición se incluyen cosas como:



¡Para poder escribir eso el autor necesita saber de sistemas operativos y cómo se ejecuta su obra el ¡¡¡línea de comando!!! en cada uno de esos sistemas! Por no hablar de que todo eso carece de sentido si la aplicación que intenta implementar ORCO es una app de un smartphone, entonces directamente el 'execute' o la posibilidad de 'incluir un nuevo intérprete' tiene que ser completamente reinterpretado.

Por todo eso, yo hubiese preferido una especificación mucho más simple, y con menos pretensión de dar tantas instrucciones de instalación o ejecución. Todas estas complicaciones deben pasarse al implementador del intérprete no a los autores, algunos de los cuales no vienen del mundo informático.

Tres veces, tres veces he dicho que el autor no necesita saber nada de nada porque la idea es que ese XML se genere automáticamente.

Son cansinas las discusiones en las que hay alguien que no quiere leer y la cosa se reduce a repetir todo una y otra vez.

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

¿La palabra "intérprete" que resalto se refiere efectivamente el intérprete o al gestor/front-end que utilice ORCO?

Yo también soy de la opinión que reinventar un pseudo-sistema de instalación en los front-end es una "locura" (para eso están las herramientas del sistema operativo) pero...

¿No pretende ORCO ser utilizado para crear uno o más front-ends que se encargue de absolutamente todo, instalaciones de intérpretes, aventuras y ejecución incluidas? Visto de esa manera, no hay más remedio que proporcionar una API de instalación. Por desgracia, como eso no está estandarizado entre sistemas (alguno ni lo tiene), hay que abstraerlo, posiblemente un poco mejor de lo que está ahora.

Puestos a no-reinventar, hay que fijarse en los sistemas de paquetes de las distros (con gestión de dependencias y madres de las stores tan de moda actualmente), en las instalaciones de las webapp (aunque ni los encargados de las especificaciones se ponen de acuerdo en cómo debe ser), etc...

El problema de base es que cada autor publica lo que le apetezce, sin que exista un estándar, y sin que podamos pretender que vaya a existir uno universal (harán un zip, un tar, con directorios, sin ellos, blobs, zblobs, agz, exe, bla bla bla).

Entiendo que ORCO proporciona un mínimo común. La aproximación actual parece ser algo cercano a bajo nivel: el sistema de ficheros y la ejecución de comandos, sobre el que montar procesos de instalación en base a pasos discretos y básicos ya que, sin soporte para instalación se echaría por tierra la razón de ser de todo esto: poder crear front-ends para usuarios no técnicos en un mundo heterogéneo en cuanto a formas de distribución y plataformas.

Los retos difíciles son los interesantes, ¿no? A veces alguien acaba haciendo algo "imposible" porque no sabía que lo era.

Una pequeña filosofada personal, algo fuera de tema:

¿? Claro que te he leído las tres veces que has dicho que supuestamente el autor no va a tener que escribir esos XML, pero es que en la práctica no hay otra, al menos no lo hay hasta que integremos alguna clase de herramienta para sacar esos XML de algo como las fichas del portal.

No me gusta el contenido del XML de la definición de ORCO, me parece innecesariamente detallado, demasiado dependientes de la plataforma y creo que de eso debe preocuparse el intérprete, como hacía puertAventura (por no hablar como ya se ha comentado en otros hilos, por ejemplo este: viewtopic.php?f=16&t=3083, ha habido otros esfuerzos de proporcionar metadatos previos).

No me acuses, Al-K de no leer algo. Yo lo leo todo. Tal vez es que no me quieres escuchar a mí. A ver lo dejo más claro:

1. Un protocolo/formato de metadatos/ficheros de instalación sin una plataforma que recoja esos datos y unas herramientas que permitan incluir esos datos no sirve de gran cosa.

2. Poner en XML algo no soluciona los problemas de nada. Me da igual que sea XML o JSON o BSON o un formato binario de campos fijos, lo que importa es que el formato sea lo más aceptado y universal posible.

3. Los campos de ejecución e instalación de la actual versión de ORCO me parecen excesivamente dependientes de las plataformas actuales. Las obras tienden a perdurar, los intérpretes y los sistemas operativos sin embargo van cambiando, por eso me parece que el campo 'execute' condena a un mantenimiento innecesario al descriptor de la obra. Creo que esas complejidades deberían estar en el intérprete, no en el fichero de configuración.

Finalmente hechas todas estas consideraciones, sea cual sea el soporte que se decida dar a un repositorio de aventuras y al intérprete que se esté usando, colaboraré en rellenar los datos necesarios como ya hice cuando web-aventura; ya que me parece fundamental que exista una herramienta así.

En respuesta al comentario final de d6: no se trata de facilitar la instalación o ejecución (que la verdad, que alguien de fuera se tenga que instalar el gargoyle, o el age-client o lo que sea, es más problemático de lo que me parece que te parece a la vista de la documentación de Burbuja ), no... desde mi punto de vista es más bien darle una apariencia de 'librería'. Cuando entras desde el Kindle a la tienda Amazon un mundo entero de 'libros' está ahí, a la mano, cuando haces el equivalente en el iPad vuelve a pasar lo mismo. Pues bien nosotros tenemos un montón de 'libros' GRATIS, que estamos deseando regalar, pero sólo cuando funcionaba puertAventura tuve esa sensación de tener los 'libros' en la punta de la mano.

El portal está bien, las fichas actuales del CAAD están bien, pero no es lo mismo. Sólo en los casos de aventuras con versión online la sensación se parece y el rendimiento de las obras Glulx corriendo en web deja mucho que desear (y en el caso de algunas Age, por ejemplo en la versión que yo he probado del remake del Libro, la diferencia entre la versión web y la de sobremesa era notoria).

Así que: jugar online? genial! Pero busquemos esa sensación de 'app' facilísima que daba puertAventura.

Es verdad que no tiene por qué ser el autor el que escriba cómo ejecutarse su obra en diferentes plataformas(no digo ya si lo hace o no una máquina), de todos modos puede haber juegos sólo disponibles para unas, o para una sólo.

Bueno, hoy no he avanzado *visiblemente* respecto a ayer, he cambiado cosas de ORCO y las comento por si se me escapa algo, la verdad que no estoy siendo muy analítico ni sesudo haciendo esto, en otras cosas lo soy, pero como esto para mí es mera práctica de programación y no sé nada de este mundo, pues voy añadiendo y quitando según me haga falta. Ruego me disculpen.



Bien, he añadido infodesc's que pueden repetirse y contienen las fuentes de la información, cuando se elije un juego se muestra en un combobox en la toolbar los tipos de descripciones que se pueden elegir. El atributo name es el que se muestra en el combo, el type es el tipo, de momento hay 2 tipos, default, que es una información insertada en el xml mismo, y url que es una url externa.
La idea es mostrarlo en el mismo componente web, y poder escribirlo en html la synopsis, de este modo no hace falta un campo para la imagen y se pueden poner enlaces y muchas imágenes, etc... Se pueden agregar más tipos, tenía pensado hacer filtros xpath para extraer parte de contenidos, puede que fuera útil.
Espero que Al-k y quien quiera pueda darme su opinión e ideas sobre esto.

He cambiado eso de que al principio esté oculto el componente web, el caso es que en cuanto se selecciona una aventura no sé si mostrar directamente el primer infodesc(como ahora, que puede ser también uno especificado como por defecto) o retornar a la lista completa, sería engorroso para el usuario que para cada aventura tuvieras que seleccionar el tipo de información que quieres.

Muy buena nota la de la seguridad, de hecho ya pensaba eliminar el comando borrar. Tengo que pensar cómo lo voy a hacer.

Mañana quizá me tome el día "libre" para estudiar ya que tengo el último exámen importante el jueves. O quizá le dedique sólo la mañana como hago todos los días.

Lo próximo será arreglar el modo de mostrar la información para sinopsis incrustadas en el xml. O quizá deje eso para más adelante y me meta con las instalaciones de las plataformas y los juegos.

----------
Acabo de leer el post de dddddd
Y respecto a lo que Al-k me contestó de que dije me parecía muy ambicioso era por eso mismo. Pero bueno, está dando muchos debates filosóficos esto y yo sólo estoy haciendo algo práctico, funcionará sí o sí, no tiene más pretensión, quizá no funcione con todos los juegos obviamente, ni a todos los usuarios, quizá sea tan cutre o funcione tan mal que nadie lo quiera usar, ¿quién sabe? pero ahí estará el intento. Lo que me importa es sacarlo adelante y aprender lo que pueda por el camino.
Me daban ganas, otro de los proyectos que se me ocurrió leyendo por el foro era hacer un intérprete de lenguaje natural en castellano en Prolog, quizá lo siguiente. Sólo lo digo porque parece que este proyecto trae polémica no sé bien porqué jajaja
--------
Respecto lo que dice Johan, yo creo que por una parte el autor de la obra tendrá que saber cómo se ejecuta la obra, de todos modos habrá una serie de formatos que se reiterarán, quizá es lo que dices(escribir código para cada formato/plataforma), en ORCO, si no me equivoco(o sino podría hacerse), eso está contemplado, los ficheros son independientes, las plataformas se pueden reutilizar, ¿no?

Jeje, quedó claro que la documentación de Burbuja dependía de fuentes de información externas, enlzadas en parte. Lo asumo y no me parece el fin del mundo en el ámbito de la comp, que es donde pretendía moverse. Precisamente da soporte a mi argumento: preguntando se llega a Roma y la gente es suficientemente inteligente.



Entonces, ¿te parece necesario que, de la lista a la ejecución no haya pasos (como la sensación que te da llegar a lo online, independientemente del rendimiento)? ¿o no?.

Si [dar pasos no te molesta]... Yo creo que las fichas del portal (búsquedas incluidas) te lo ponen en la punta de la mano Es posible que haya que remodelar los listados para adaptarlos a tu gusto, pero eso no creo que tenga nada que ver con ORCO, y lo podemos hablar en otro hilo, encantado de oir sugerencias.

Si [lo consideras problemático], entonces hace falta poder instalar/ejecutar sin intervención. La diferencia es que todo el mundo suele tener un lector de PDF (o el propio dispositivo viene de fábrica con ello) o utilizan el sistema de paquetes del dispositivo (uno a uno tienda/aparato) y nuestros "libros" son más complejos de ejecutar. Igual deberíamos crear un dispositivo cerrado y controlado para ejecutar aventuras ;P

EDITO: para aclarar, entre corchetes, una doble negación que me confundió.

No, hombre, no. ¡Si aquí se discute siempre!

Y creo que hablo en nombre de todos si digo que el resucitar este proyecto es algo que nos tiene encantados.

¡Ah, no! Por eso no te preocupes. Desde que estoy en el Caad, que no es hace mucho tiempo, no he visto a nadie tomar una iniciativa, por nimia que fuese, sin que se generasen vehementes discusiones. (En realidad es lo que les mola, creo que más que las aventuras Y este nivel de discusión, para ser por aquí, lo podría denominar como "consenso".

Por mi parte yo también estoy encantado con el proyecto. Sigue adelante, por favor, y gracias.

Vaya, está bien eso del consenso, no me malinterpreten(ya saben que es clásico de los foros los flames y uno está acostumbrado a que la gente se pelee por nada, no es el caso), y no pienso abandonar el proyecto, intentaré llevarlo lo más lejos que pueda, aunque en cuanto saque una versión usable me distanciaré más para comenzar otros. Gracias por el apoyo! aunque aún no me hace falta demasiado, pero no está mal, así da gusto jaja