Cambio de librería
Pablo Costesich
libedb para reducir tamaño. Se supone que es 100% compatible y que en
todo caso se puede cambiar sin problemas sólo reemplazando el jar.
Actualmente estamos usando la librería Sqlite por Zentus
(http://www.zentus.com/sqlitejdbc/). Propongo usar la de Xerial
(http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC#WhatisdifferentfromZentussSQLiteJDBC),
que le agrega un "superset" y genera sustanciales mejoras (según
ellos) sobre el desempeño y el tamaño. De 2.2Mb pasaríamos a 890Kb
sólo con nativas.
Otra diferencia es que la de Zentus está en BSD compatible, y la de
Xerial en Apache 2.0 (también compatible). La ventaja es que el resto
del proyecto Xerial también lo está, y como incorpora un montón de
librerías para XML es capaz de que libexml sólo sea una pequeña capa
de negocio, por ende, rápida para diseñar.
Si no es molestia, sugiero que le des una leída al proyecto, parece
interesante: http://www.xerial.org/trac/Xerial
Alvaro Durán Tovar
> He decidido que sería una buena idea cambiar la librería que usa
> libedb para reducir tamaño. Se supone que es 100% compatible y que en
> todo caso se puede cambiar sin problemas sólo reemplazando el jar.
>
> Actualmente estamos usando la librería Sqlite por Zentus
> (http://www.zentus.com/sqlitejdbc/). Propongo usar la de Xerial
> (http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC#WhatisdifferentfromZentu
> (según
> ellos) sobre el desempeño y el tamaño. De 2.2Mb pasaríamos a 890Kb
> sólo con nativas.
>
> Otra diferencia es que la de Zentus está en BSD compatible, y la de
> Xerial en Apache 2.0 (también compatible). La ventaja es que el resto
> del proyecto Xerial también lo está, y como incorpora un montón de
> librerías para XML es capaz de que libexml sólo sea una pequeña capa
> de negocio, por ende, rápida para diseñar.
>
> Si no es molestia, sugiero que le des una leída al proyecto, parece
> interesante: http://www.xerial.org/trac/Xerial
Ok. voy a descargarlo ahora y probarlo en EntrenadorRO, que hace uso de sqlite.
Lo he estado mirando y tiene buena pinta.
Aún no voy a modificar EntrenadorRO para que use las librerías que estás creando porque requeriría un esfuerzo
considerable, y por ahora estoy centrándome en el programa principal solo, espero que lo entiendas.
Pablo Costesich
>
> Aún no voy a modificar EntrenadorRO para que use las librerías que estás creando porque requeriría un esfuerzo
> considerable, y por ahora estoy centrándome en el programa principal solo, espero que lo entiendas.
>
No te preocupes, no gastes tiempo en modificar algo que ya anda. La
librería está hecha para facilitar la tarea, y todavía le falta
bastante por delante para terminarla... Sólo que mañana tengo mucho
para hacer, el martes rindo un pequeño parcial y la otra semana ya
empiezan los exámenes grandes.
Aprovecho para contarte un par de cosas (estoy un poco corto de tiempo):
-Genial lo de Anpu, voy a cambiar eso de las ciudades cuando pueda. Es
agregar "ORDER BY name ASC" en la consulta.
-La librería libedb NO va a ser compatible directamente con librolgps.
Tal vez haga una capa de abstracción extra para la transición, pero
quiero tirar los lastres de librolgps y las fallas de diseño que
ocurrieron por empezar por donde no debía.
-Después escribo lo que pienso hacer de libedb. Es simple, y hasta
debería poder utilizarse por alguien que no sepa sql (con un
queryBuilder, en el propio libedb).
Por otra parte, te cuento lo del IPC que me queda pendiente:
IPC significa Inter Process Communicator. Es un agente de transporte,
al estilo de sockets o incluso un mailer que manda información de un
proceso a otro. Mi idea era partirlo en dos: una que sea la librería
cliente y otra el servidor. El uso debería ser más o menos así:
Uno invoca al servidor persistente, que se encarga de escuchar en un
puerto para conexiones entrantes en un thread. Cuando un nuevo cliente
se conecta, lo autentica (o sea, verifica que el nombre no esté
repetido) y publica los servicios que tiene. Eso queda en el servidor,
almacenado para cualquier query posterior. Para no ocupar nuevos
puertos, los clientes deberían checkear cada x cantidad de tiempo si
tienen mensajes en el servidor, quien les envía los datos. Suena
simple, pero tengo un despelote tremendo para crear un protocolo.
En otras palabras, el único servidor es el Servidor IPC. Ninguna
aplicación tiene su propio server, sino que se conectan cada unos
cuantos milisegundos al Server IPC y solicitan mensajes.
¿Qué es eso de los servicios? Suponete que RO_MAP se conecta al IPC.
Tiene que avisarle en el handshake su Nombre y Función. Si ro-npcs
decide mandar un punto o una serie de puntos al IPC, entonces se
identifica (sólo una vez, al inicio) y envía mensajes con un
destinatario genérico como "regnum map". El IPC guardaría esos datos
(en una tabla, por ejemplo) y esperaría a que algún "regnum map" se
conecte y pida datos.
Tengo problemas con mezclar sockets y threads. En especial con el tema
de timeout en la conexión, ya que si queda abierta entonces podría no
necesitar ese protocolo de pregunta-respuesta y sólo debería mandar
datos... Pero ahí debería incorporar un mensaje de "hangup" para
cortar la comunicación.
Alvaro Durán Tovar
Pero yo haría una cosa para evitar el checkeo cada X milisegundos. El que un cliente tenga que estar checkeando se
hace muy muy pesado, además innecesario.
Yo implementaría algo parecido al patrón observer y no tienes que preocuparte del lado del client, todo se hace en
el servidor.
Sería algo así:
Se registran varios plugins y se almancena su información (nombre). En un momento dado el plugin P1 quiere mandar un
mensaje a P2. P1 manda mensaje a servidor con destino P2. Entonces servidor manda el mensaje a P2, no es P2 el que
lo solicita. ¿No ves mejor que los clientes estén ocupados si mismos excepto cuando les llega un mensaje, sin
necesidad de solicitar mensajes?
Suerte con el parcial!!
PD: No dijiste si quieres que ponga algún comentario y/o foto en el foro inglés :P
Pablo Costesich
> Yo implementaría algo parecido al patrón observer y no tienes que preocuparte del lado del client, todo se hace en
> el servidor.
>
> Sería algo así:
>
> Se registran varios plugins y se almancena su información (nombre). En un momento dado el plugin P1 quiere mandar un
> mensaje a P2. P1 manda mensaje a servidor con destino P2. Entonces servidor manda el mensaje a P2, no es P2 el que
> lo solicita. ¿No ves mejor que los clientes estén ocupados si mismos excepto cuando les llega un mensaje, sin
> necesidad de solicitar mensajes?
Sí, eso es lo que quiero hacer, el problema viene por el lado de cómo
lo implemento con sockets. Creo que lo más simple va a ser que en el
protocolo haya un mensaje exit o shutdown que corte la conexión.
Quería utilizar el timeout de un socket para controlar la lista, ya
que ante cualquier falla es un tanto más redundante.
Hoy veo de imprimir un par de apuntes sobre esto.
Otra cuestión es que el IPC implementaría una db en sqlite, por lo
cual no habría mucho problema en mantener una db centralizada.
>
> Suerte con el parcial!!
>
> PD: No dijiste si quieres que ponga algún comentario y/o foto en el foro inglés :P
>
>
¡Adelante! Es una buena idea, además así te dan un poco de karma. En
todo caso te ayudo a redactarlo. :P
Gracias! :D