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 [email protected] 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.

Bueno, en todo caso, yo lo primero que tengo que decir es que el uso de plugins lo haria el caso de que se usase, minoritaroio. Lo suficiente para implementar scripts.=20 La principal ventajas de estos ultimos es, la portabilidad. Nosotros no necesitamos velocidad. En respuesta a Batchdrake:

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=F3n. No quiero decir que yo me oponga a un lenguaje de scripting, nada m=E1s lejos de la realidad.; s=F3lo que puede haber = cosas que necesitemos implementar y que el script sea incapaz de hacer.

Esto es cierto, hasta cierto punto. Ciertos interpretes de lenguajes script (vease Lua, guile) los cuales dan una libreria para su uso en programas, permiten el uso de librerias en si mismos. Es decir, nosotros hariamos publicas ciertas llamadas, el API, pero ademas, se pueden importar mas funciones en modo de libreria.

b) M=E1s f=E1cil de mantener. La gente puede enviarnos sus plug-ins = en vez de sus parches. Es m=E1s, esto es algo que llama mucho: A la gente l= e gusta m=E1s programar de cero una mejora mediante unas reglas b=E1si= cas que empezar a rebuscar en el c=F3digo para a=F1adir una nueva funcionalidad.

Por supuesto, pero en esta opcion los scripts superan a los plugins escritos por ejemplo en C. Pueden enviarnos sus scripts.

d) Por qu=E9 es f=E1cil, qu=E9 demonios. Con dlopen/dlclose/dlsym/dl= error tenemos todo lo que podamos necesitar.

Ahi no puedo estar deacuerdo. Quizas fuera para nosotros mas facil implementar el API, pero no de cara a que luego TODO funcionara mediante plugins. Mediante un lenguaje script suficientemente agil los addons serian minusculos. El tema de como implementarlo creo que es otro, primero debemos aclararnos respecto a usar plugins, y de ahi implementar soporte para interpretes.. o usar un lenguaje interpretado solamente. Como conclusion, personalmente tiendo a tirar por el uso de scripts. Pero sera cuestion de debatir :-)