Ultimos dias en los que le he podido pegar un empujon grande a suzie aka "mi proyecto de bot multiprotocolo/servidor de mini-aplicaciones".

Creo que ha llegado la hora de explicar un poco en que consiste suzie:

Muchas veces he tenido mini-aplicaciones (en adelante scripts) para realizar pequeñas tareas, tales como una consulta para ver que correo tengo, que tiempo hará mañana, consultar la cartelera del cine y demás.

Todos estos scripts están bien, pero no tienen APIs ni código compartido y su formato es irregular y no utilizable.

Suzie intenta ser todo esto, una capa comun para aportar a todos estos scripts estas cualidades, además de un repositorio común donde unirlas todas.

Otra cualidad de suzie es que no se limita a la consola, ni esta enganchado a un protocolo. Los scripts que se integran en suzie no conocen nada del canal por el que escuchan y por el que contestan, esta parte se ha abstraído a otro nivel: los Monitors.

Básicamente este el esquema del funcionamiento de suzie (click para ampliar)

Nuestros Workers únicamente manejan mensajes, que contienen quien lo ha enviado, para quien de ellos y lo que ha enviado, ellos simplemente tienen que escribir en el mensaje su contestación.

Todo esto entra y sale del sistema por los monitores. Todos ellos están vigilados por el Core, en cuanto se recibe algo por alguno de ellos se lee el mensaje y se mete en el túnel de procesado del cual saldrá mas tarde por el otro lado con la respuesta adecuada y el Core enviara esta contestación por el mismo canal por el cual ha llegado.

Todo esto junto hace que:

Además hay cosas algo mas marcianas que dan para otro post como:

Al final el post me ha superado y el resto lo dejo para otro día.

Salto de calidad en suzie:

• Los monitores pueden generar otros monitores, de hecho los monitores 'inet' y 'unix' ya generan monitores 'socket' ante una conexion. Esto significa que he superado la barrera que siempre me frenaba a acabar este proyecto
• Suzie dispone de un cron interno, basicamente se consigue usando la llamada poll de la clase monitor y generando un mensaje cada cierto tiempo
• Tanto trabajadores como monitores disponen ahora de memoria, con lo que pueden mantener un recuerdo de lo que habian hecho anteriormente, esta memoria se podra conservar entre ejecuciones en un futuro
• Implementados con exito los monitores 'tty', 'inet', 'unix' y 'cron'
• Como prueba se ha implementado un trabajador logger :)

• Exámenes.

  Duro fin de semana:
  Viernes examen de "Gestión de servicios de internet": rsync, ssh, http, vnc, smpt, etc. Fácil pero no deja de ser un examen.

  Lunes algo que parecía sencillo a primera vista: "Administracion de sistemas operativos". Una sanguinolenta matanza que nadie se esperaba, mi pésame a todos los que estuvimos allí.

• Frikismo.

  Tras el final de exámenes se abre la veda para liberar el frikismo acumulado y retenido a duras penas durante el ultimo mes.

  Instalo icecast2 e ices2 en mi servidor de casa, consigo tener una radio interna emitiendo en ogg 24/7, pronto el howto.

  Trabajamos un poco en Suzie para que los monitores sean capaces de generar monitores, además consigo hacer funcionar el cron interno de suzie mediante una custom-poll y monitores

Hemos llegado al punto critico de mi historia personal con suzie: crear un monitor desde un monitor:

Los monitores (puntos de entrada/salida) generan mensajes que normalmente son el texto que ha entrado por el monitor.

Pongamos como ejemplo el monitor 'inet', este monitor escucha un puerto a la espera de una conexion, bien, suzie detecta esta conexion pero este evento NO debe generar un mensaje, si no otro monitor al que escuchar.

Suzie, mi asistente personal. Muchas veces he pensado en este proyecto, pero creo que pronto podre implementarlo.

Suzie se basa en el siguiente concepto:

• Tenemos una serie de pequeños programas que realizan funciones, llamemosles 'workers'
• Tenemos una serie de funciones que nos permiten leer/escribir desde diferente canales (stdin/stdout, jabber, web, mail, msn, ...)
• Un 'core' o director que se encarga de monitorizar las entradas, extrae el mensaje puro, el mensaje pasa por todos los 'workers' para ver si deben hacer algo con él.
  Una vez se ha procesado el mensaje se devuelve por el mismo canal que habia llegado.

Finalmente y tras probar varias implementaciones, Suzie sera perliana.

A bote pronto necesitare varios modulos:

• Core: Implementara la vigilancia I/O, timeouts y tal vez control de acceso
• Monitor: Clase que permitira crear nuevos puntos I/O
• Worker: Creara nuevos trabajadores de la cadena de procesado
• Tunnel: Controlara el paso del mensaje desde la salida del Core a traves de los 'workers' hasta su vuelta al Core para su devolucion al origen