Open Virtual Container

A raiz de la entrada Encaminados a la primera Release
Hemos encontrado algunos problemas tecnicos que van a retrasar esta entrega. No obstante hemos avanzado en muchos aspectos que queremos hacer notar asi como también queremos hacer notar que la versión actual del programa de pruebas test2 solo puede ejecutar su primera función hasta el destructor. Despues experimenta un bloqueo que tenemos que depurar.

Actualmente la version que está en el svn seria capaz de hacer lo siguiente:

Muy buenas,

Os escribo para informaros que pronto vamos a realizar la primera release a causa de el gran movimiento que está existiendo en el planet. Hemos decidido que igual para el martes que viene vamos a publicar los siguientes elementos:

Hemos analizado las distintas alternativas que existen para empaquetado-compresión de objetos.

En principio hemos probado las siguientes librerias:

* Zlib (www.zlib.net)
* libtar (http://www.feep.net/libtar/)
* unzip (http://www.info-zip.org/)
* zlib-1.2.3/contrib/untgz/ (www.zlib.net)
* 7z (http://downloads.sourceforge.net/sevenzip/lzma457.tar.bz2)

En la arquitectura OVC, se incorporó desde el inicio la idea de utilizar un lenguaje que sirviera de intermediario entre las capa IO y Builder (o IO::Parser y Builder para ser más exactos). El propósito de este lenguaje era el de simplificar la creación de módulos Builder mediante la extensión en el número de formatos que serían capaz de soportar. La idea es simple: cargar a IO un parseador de formatos (gráfico, audio, física, etc.) que genere un lenguaje para los módulos builder que sea un estandar ampliamente documentado y soportado por la comunidad. De esta forma la implememtación de los módulos builder puede centrarse en el formato de destino, ignorando el formato de origen siempre que éste sea parseado por IO.

Por fin carga los modulos de todas la capas de una manera eficiente y con autodetección, se han realizado cambios en la forma de nombrar los modulos de tipo bulder para que funcione la autodetección.

A partir de ahora ya es posible hacer mRead("graphics") y el programa buscará en la capa builder, si existe un modulo con ese nombre y sino, bajará a la capa io y lo buscará alli. En caso de no encontrarlo devolverá el error correspondiente de modulo no encontrado.

Hemos conseguido enlazar nuestro primer modulo, es de tipo File, y nos ha devuelto su primer "funcion no implementada"!. Esto nos ha llevado varias horas de modificaciones en configures.ac y makefiles.am, no esperabamos tanta complicación despues de tanto tutorial y pelea.

Ahora tras conseguir la comunicación con los modulos, pasamos a la fase 6, implementación de módulos graphics. Hasta ahora los modulos los hemos dejado hasta construir el controlador, que es la parte esencial de la arquitectura. Sabiendo que esto funciona y con nuestro creador de modulos, podemos crear modulos rapidamente peleandonos ya con los pequeños problemas de las librerias de alto nivel que vamos a usar.

En principio para esta fase vamos a utilizar intensivamente Irrlicht, irrlicht para la lectura del xml, irrlicht para la conversión a lenguaje intermedio y un modulo lenguaje inermedio-objeto irrlicht listo para ser usado en la aplicación de usuario.

Se ha completado el desarrollo de los constructores de los distintos controladores los cuales se encargan de inicializar las capas Builder e IO.
Básicamente se inicializa la librería ltdl y se construyen los mapas de cada capa con los respectivos módulos localizados en el directorio de trabajo especificado, listos para ser cargados cuando los requiera el usuario.

Ya hemos terminado este caso de uso. Ahora mismo debe ser capaz de leer un fichero y dar las ordenes adecuadas a los modulos de la capa io para que ese fichero sea preparado para la carga.

Acabo de actualizar el SVN con los ultimos cambios. He conseguido hacer que el programa se ejecute tanto en linux como en windows de manera automatica ejecutando compile.sh.

Hemos tenido bastantes problemas, por lo que voy a dejar aqui una nota para todos aquellos que quieran desarrollar con libtool. Por lo visto bajo windows no se puede añadir en la sección xxx_la_LIBADD nada estaticamente, ya que se marea, el truco, y esto ya lo he dicho en otro momento, está en añadir los fuentes directamente.

Se ha terminado el caso de uso OVC Read desde el punto de vista de los controladores.

En teoria y una vez que se desarrollen los modulos de IFile, IModule e IParser, podremos tener un objeto funcionando en una aplicación de usuario.