Avances en desarrollo

Avances en desarrollo

de Guillermo Andrés Fernández Cotelo -
Número de respuestas: 1
Resumiendo un poco, ayer (martes 11/7) dedicamos tiempo más que nada a armar el entorno que a otra cosa, tuvimos problemas para que la vm de german tenga internet para acceder al svn y demás que logró solucionarlas el día de hoy.
Llegué a probar el svn con la nueva password que nos mandaron y pude descargar y subir cosas; solo hay que tener presente un tema al trabajar en el laboratorio de medios que lo mencionaré en otro hilo para que quede.

Germain encontró una librería para serializar objetos en c++, quedo en probarlo un poco para implementar el módulo configuración con la misma.
Yo quedé en ver cómo se comunicarán los módulos y la PUI (definir el formato de datos de definición de los eventos, marcado y contexto), que sirva para hacer el reflection de eventos implementando así también el modulo eventos.

El lunes 9/7 estuvimos entre otras cosas viendo cómo sería un comportamiento típico donde se contemple el chequeo de cambio de contexto y pensamos que capas serviría que la información de eventos para cada contexto (relación entre marcas y eventos) se vaya cargando a medida que es necesario. Seguro nos fuimos un poco por las ramas pero como lo hablamos lo menciono. Adjunto un diagrama que hicimos del comportamiento para que se entienda mejor.

Saludos
En respuesta a Guillermo Andrés Fernández Cotelo

Re: Avances en desarrollo

de Usuario eliminado -
Bien, buenísimo que quedaron los entornos de desarrollo funcionando. Bien Guille por hacer el post explicando como configurar el proxy, es conocimiento que ya nos queda para el futuro.

Bueno ahora que tenemos todos los problemas técnicos solucionados tratemos de meternos de lleno en el diseño e implementación de lo propuesto.

Germán:
Creo que antes de ir al detalle de que biblioteca o herramienta vamos a usar para guardar y cargar la configuración sería mejor que presentes el diseño de la solución. Me refiero mas bien a como vas a resolver el problema , necesitas un diseño que permita: (lo que está en el cronograma)

  • Definir el comportamiento de los marcadores según la aplicación que se esté ejecutando.

  • Cada marcador tiene asociados un conjunto ordenado de eventos para cada aplicación para la cual se quiera definir el comportamiento del marcador

  • Cada marcador debe de tener un conjunto de propiedades dinámico

Ahora, es necesario presentar la solución que nos va a permitir hacer cada uno de los 3 puntos anteriores. Podes ayudarte con un diagrama, con un xml que sirva de plantilla, etc. La idea es definir la jerarquía y las relaciones entre las clases diseñadas.Por ejemplo para cada marcador hay un conjunto de contexto y eventos no es lo mismo que para cada evento hay un conjunto de marcadores y contextos. Las visibilidades cambian y las formas de representación también. Me explico?
Luego de saber como se deben relacionar las clases y que jerarquía tienen , evalua las alternativas de persistencia que tenemos, a mi se me ocurren 3:
* xml
* Sugar datastore (http://wiki.laptop.org/go/Sugar.datastore.datastore)
* Gconf

La mas atractiva creo que es Sugar Datastore porque es una solución ya integrada con Sugar y porque te evitarias el uso de una biblioteca externa para el parseo y serialización de objetos (me parece). Igual, estaría bueno que lo investigues y evalues la mejor herramienta, yo sinceramente no se cual es la mejor!

Por último, nos falta implementar el módulo que se encargue de estas tareas.

Guille:

Estuve viendo lo que plantean del cambio de contexto y creo que no justifica hacerlo a demanda, de hecho, en algunas circunstancias puede hasta ser mas lento.

Supongamos que tenemos la estructura de almacenamiento de eventos, marcadores y contextos de la siguiente manera:

|M1| ---------> | C1|
| | | C2| -------> [e1,e2,e3]
|M2| | C3| -------> [e'1,e'2,e'3]
| |
|M3|
| |
|M4|
------


M = Marcador
C = Contexto
e = Evento


Los M que son los marcadores, van a estar todos cargados en memoria si o si.
Los C, representan los contextos, o sea que son objetos con un identificador que como mucho es un char[255], por lo tanto redondeando van a pesar 300bytes cada uno.

Los e son los eventos, que basicamente tienen una funcion "disparar", exageradamente pesan 15kb.

En un caso extremo vamos a tener
20 Marcadores cargados, 10 contextos y 3 eventos por cada marcador y contexto.... o sea que por cada marcador tenemos en memoria:

(15kB + 300bytes) * 10 = 160KB ... (verificar la cuenta que puede ser cualquier :p)

No es nada de memoria no? Me parece mejor cargarlo todo de una, tenerlo todo en memoria y hacer busquedas en arreglos antes que pedirle a un modulo de configuracion que nos busque la información para cada contexto no cargado (que probablemente termine en buscar cosas adentro de un archivo de texto lo cual no es muy veloz).

Creo que por el momento no requerimos hacerlo a demanda y el tema memoria no sería un problema. Si nos ponemos de acuerdo con esto entonces ya podes definir las interfaces para comunicar la PUI y los 2 nuevos módulos, Eventos y Configuración.

Cambio las fechas en el cronograma y lo adjunto, les parecen bien? Nos quedan 2 semanas y un poquito para comenzar el nuevo semestre de Nexo y tenemos que liquidar esto antes de arrancar con otra cosa.

Estoy para meter código, configurar, dar una mano o lo que sea, pero necesitamos tener un poco mas avanzado el tema antes del lunes para aprovechar el espacio del laboratorio y laburar todos sobre el diseño y las implementaciones que traigan. Les parece?


Abrazo
Seba