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