libTransport
Alvaro Durán Tovar
Espero que te vaya bien con los exámenes. No he mirado muy detenidamente las librerías xD, pero he vista una cosa
para comentarla.
En la clase Body (del paquete protocol creo) por como está estructurado tal vez sea útil usar un tabla hash
(java.util ya tiene una), tal vez eso ahorre o ayude la implementación.
Solo esa idea, saludos!!
Pablo Costesich
Sí, estuve viendo eso de la tabla hash, pero no sé si implementarlo
así. Se supone que se pueden enviar múltiples tags del mismo estilo, y
según tengo entendido al hashear los resultados entonces pierdo esa
capacidad.
Un mensaje sería:
<message>
<header>
<messageType>
0
</messageType>
<sendToMessenger>
Arlick
</sendToMessenger>
<sendToServices>
Developers,Users,Beatesters
</sendToServices>
<messengerName>
Xephandor
</messengerName>
</header>
<body>
<text>
Hola Mundo!!!
</text>
</body>
</message>
Es MUY IMPORTANTE el caracter de nueva línea y los tabs, por ahora.
Luego voy a hacer una regex para no tener que meter tantos saltos y
también para identar, pero ahora quiero mantenerlo simple (por el
parser).
Básicamente, lo parsearía con información al estilo mail. Pensá en
SendToMessenger como un indicador monario, porque de esa forma evita
sobre-saturar el envío con una especie de DoS. Es decir, para enviar a
n plugins tendrías que repetir el proceso n veces, con lo que resulta
más simple de kickear a un plugin si se quiere pasar de la raya. Del
otro modo es más difícil.
Sin embargo, existe algo para notificar a todos los de una misma
familia: sendToServices. El servidor se encarga de que no haya muchos
suscriptores en una lista, así que no hay problemas de DoS allí.
En resumen: en header va toda la info que el servidor o el Messenger
necesite saber. En body los datos en sí que el usuario utiliza.
Todavía no encuentro una forma de implementar el patrón observer de
manera útil. Lo veo interesante...
Voy avanzando, aunque todavía no es la parte más difícil. :D
PD: libedb también está complicada, más que nada la parte del Manager.
Pablo Costesich
Primero: para tener algo testeable sólo faltan implementar algunos
métodos y la estructura del SocketListener, encargada de procesar las
respuestas y ejecutar las llamadas de aviso. Luego hay que implementar
todo ConnectionProperties
La idea es que uno instancia un nuevo Messenger, luego le carga todos
los listeners y lo invoca en su propio thread. Para agregar un
listener, la clase que contiene los métodos que van a manejar un
suceso deben implementar CommEventHandler, que son los métodos a los
que el Observer llama. Los métodos (hasta ahora) son: newMessage,
messengerShutdown, serverDied y assignedProperties, y cada uno es
llamado cuando llega un mensaje.
¿Para qué está cada uno?
void newMessage(Message message): pasa el mensaje P2P que le llegó al
Messenger. Nunca te llegan los mensajes de sistema, sólo los de
plugin-a-lista o plugin-a-plugin (cuando se recibe no se puede
diferenciarlos). ;)
void messengerShutdown(): cuando se llama el proceso de apagado, el
Messenger envía el requisito al servidor, que luego de aceptarlo le
responde, lo saca de la lista y corta todas las conexiones. Esto sirve
para apagar el programa de una forma ordenada.
void serverDied(): lo mismo que el anterior, pero el servidor no
responde o lanza una excepción. La idea es que de este modo se capture
el error de una manera limpia.
ConnectionProperties assignedProperties(ConnectionProperties props):
una vez conectado llama a este método. Debería devolver el nombre del
plugin con el que fue registrado, los servicios actuales y el
directorio de usuarios. Para actualizar los datos se envía un mensaje
con el método factoría "updateList" de ConnectionProperties.
Hay un "enforcing bug". El Messenger no considera como erróneo que se
manden mensajes de sistema desde fuera del generador. En realidad
nadie va a tocar eso, pero por las dudas debería implementarse.
Al final esto resultó mucho más complejo que implementar D-Bus... Pero
el 90% de lo que estoy usando lo aprendí ahora, y con D-Bus no lo
hubiese visto jamás.
Creo que el Proyecto Rolgps está creciendo por sobre los límites que
habíamos planeado. Eso es bueno, al menos si tenemos en cuenta el
avance que logramos y la forma en que se resolvieron los problemas.
Por una parte, encontré que el mayor problema está en empezar desde
atrás: librolgps no debería existir como tal y tampoco debería
llamarse así, mientras que libTransportLink es una pieza fundamental
del IPC a pesar de ser la librería... Porque es necesaria tanto por el
cliente como el servidor (define un estándar en el parser, mensaje y
un par de datos más).
Creo que luego de esto me concentraré en libedb, aunque ya mismo es
utilizable. Lo que falta allí es terminar el Manager y el
QueryBuilder, que son métodos "ayudantes".
Alvaro Durán Tovar
El próximo plugin que necesite de sqlite trato de usar libedb :P
Lo de que crezca sobre los límites... siempre uno va a querer mejorar y mejorar infinitamente lo que ha hecho. Hay
que saber encontrar un punto entre la obsesión y la calidad. A mí me gusta como hobby y por aprender todo lo que
aprendo.