[Slabot-devel] Por qué es bueno que slabot haga uso de plug-ins

Sat Jun 23 17:45:12 CEST 2007

El Saturday 23 June 2007 17:24:35 Gonzalo José Carracedo Carballal escribió:
> Voy a dar unas cuantas razones para ello:
>
> a) Porque todos sabemos que un lenguaje script, por muy potente que
> sea, es un lenguaje de script. Y va a estar limitado por su propia
> definición. No quiero decir que yo me oponga a un lenguaje de
> scripting, nada más lejos de la realidad.; sólo que puede haber cosas
> que necesitemos implementar y que el script sea incapaz de hacer.
>
> b) Más fácil de mantener. La gente puede enviarnos sus plug-ins en vez
> de sus parches. Es más, esto es algo que llama mucho: A la gente le
> gusta más programar de cero una mejora mediante unas reglas básicas
> que empezar a rebuscar en el código para añadir una nueva
> funcionalidad.
>
> c) Nos obligaría a cuidar el código, flexibilizarlo, simplificarlo y,
> en resumen, mejorarlo en calidad. Esto es una consecuencia de lo
> primero: Si la gente quiere programar un plug-in / extensión es porque
> no quiere leerse el código entero del robot, así que tendríamos que
> cuidar las funciones, esperar bugs inesperables, suponer los métodos
> del colaborador que quiera contribuír con su extensión, etcétera.
>
> d) Por qué es fácil, qué demonios. Con dlopen/dlclose/dlsym/dlerror
> tenemos todo lo que podamos necesitar.
>
> Eso por una banda. Por otra, está la implementación de esta capacidad.
>
> ¿Cómo lo haríamos? Bueno, yo con pBot he tenido tiempo de evaluar los
> problemas que más se presentan con los plug-ins, y yo propongo lo
> siguiente:
>
> Cada plug-in debería ser una biblioteca dinámico-compartida (*.so),
> que ha de exportar una serie de símbolos equivalentes a todo esto:
>
> - Nombre del plug-in: Una cadena de caracteres con un identificador
> descriptivo (por ejemplo... "antifloood" o "chanlimit"), con el fin de
> evitar la carga del mismo plug-in dos veces (estando, por ejemplo, el
> fichero dinámico-compartido copiado con otro nombre en el mismo
> directorio, o estando el mismo fichero en dos directorios de carga).
>
> - Símbolo de carga: Una función que "prepare" el plug-in para
> funcionar, en el momento de su carga. Así se podría hacer una función
> que devolviese int, para saber si la carga es o no posible (por la
> razón que sea).
>
> - Símbolo de descarga: Lo mismo, un símbolo que desreferencie todos
> esos recursos que pudiese haber reservado. Aunque, bien visto, esto se
> podría sistematizar y llevarse a cabo por el propio slabot si
> asignamos cada recurso interno al plug-in que lo solicite.
>
> - Símbolo con comentarios y cualquier otra cosa que pudiese servir
> para identificar el plug-in, describir su cometido, etcétera.
>
> Esto es un esbozo, lo que a grandes rasgos debería ser un plug-in.
> Obviamente, hay mucho que discutir sobre esto, pero como quien dice
> esto todavía está saliendo del cascarón. De todas formas, la idea
> queda ahí.
>
> Saludos

Buenas, soy nuevo en la lista por lo que antes de nada, presentarme, mi mail 
es blak.ks at gmail.com y mi nombre es Juanjo, me parece un proyecto interesante 
y al que puedo ayudar en la programación.

Debido a que no se muy bien de que va el tema, me aventurare a hacer una 
conjetura, imagino que debe de ser sobre la elaboración de plugins para el 
bot, por contra tuya, pienso que un lenguaje script seria la mejor manera de 
implementar plugins, pues las limitaciones a la que estos se someten... ¿has 
tenido muchas limitaciones en cuanto a perl, o a python? francamente, un 
lenguaje script no tiene el pq verse limitado, y actualmente no se ve, y 
seria la mejor forma de modularizar el proyecto y de crear un bot totalmente 
personalizable, y en cuanto a las mejoras, ¿porque mediante el uso de un 
lenguaje script no pueden empezar de 0?.

Espero no haberme ido mucho del tema.