Idear mecanismo de plug-ins

[GoogleCodeExporter]

Recopilar información y ejemplos acerca de la integración de dlls 
dinámicamente mediante algún mecanismo extensible y sencillo, para poder 
añadir funcionalidad externa en distintos puntos del motor sin necesidad de 
recompilación del mismo.

Original issue reported on code.google.com by Lince3D@gmail.com on 27 Sep 2010 at 7:44

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 27 Sep 2010 at 7:45

• Added labels: Section-System

[GoogleCodeExporter]

Enlaces de interés:

http://www.nuclex.org/articles/5-cxx/4-building-a-better-plugin-architecture

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2015.pdf

http://willperone.net/Code/codedll.php

Original comment by Lince3D@gmail.com on 2 Oct 2010 at 12:23

[GoogleCodeExporter]

Lectura recomendada:

C++ for Game Programmers, Capítulo 11

Original comment by Lince3D@gmail.com on 2 Oct 2010 at 12:51

[GoogleCodeExporter]

Mirando lo del loggin he visto que Poco tiene algo para soportar carga dinamica 
de clases, por si fuera útil:

"For loading (and unloading) shared libraries at runtime, POCO has a low-level 
Poco::SharedLibrary class. Based on it is the Poco::ClassLoader  class template 
and supporting framework, allowing dynamic loading and unloading of C++ classes 
at runtime, similar to what's available to Java and .NET developers. The class 
loader framework also makes it a breeze to implement plug-in support for 
applications in a platform-independent way."

Original comment by jwl...@gmail.com on 13 Oct 2010 at 8:25

[GoogleCodeExporter]

La carga de .dll o .so dinámicamente se refiere a el uso que se hace del 
linkeo de las funciones/clases/métodos/etc que componen una API o librería, 
así se logra la modularidad, y también la expansión de una forma "estática" 
por así decirlo, cuando expandas deberán ser exactamente los mismos métodos 
con los mismos parámetros etc, aunque si es el caso, la funcionalidad puede 
haber recibido mejoras, pero siempre manteniendo eso, lo cual no me parece que 
es lo que están buscando.

Creo que tu piensas en el mecanismo dlopen, este es el mecanismo que empezó a 
usarse con netscape para los plugins, simplemente con poner una nueva .dll o 
.so en el directorio de plugins, cuando se volvía a abrir el navegador (creo 
que el mozilla sigue la tradición) recarga todas las librerías que encuentra 
en ese directorio, esto se logra gracias a la implementación de una librería 
de apuntadores a función que cargan las funciones (siempre el mismo numero y 
orden) volcando esto sobre una estructura de apuntadores a función desde donde 
se realizan las llamadas (así funciona dlopen) y casi cualquier librería que 
haga eso lo utiliza por debajo (supongo que sera el caso de POCO, aunque no lo 
conozco). Si usas o no una librería en lugar de utilizar directamente dlopen, 
supongo que dependerá de la flexibilidad que te ofrezca esa librería y de lo 
que tu cuanto de flexible necesites que sea. Cuando se llega al punto de 
necesitar usar dlopen en C++ no he visto elegantes soluciones, pero al igual 
que en C funciona. Este mecanismo puede potenciarse con el RTTI de C++, que 
juntos y bien combinados puede hacerse verdaderas maravillas como elegir que 
cargaras mientras ejecutas, detectar que clase estas pasando en un template y 
cosas similares, pero es bastante complejo de hacer y normalmente tendrás que 
caer en la programación genérica.

Original comment by mamig...@gmail.com on 15 Oct 2010 at 10:04

[GoogleCodeExporter]

Serie de artículos sobre como hacer un framework para plugins

http://www.drdobbs.com/cpp/204202899;jsessionid=OYHQSSSLOGFZNQE1GHPCKHWATMY32JVN
?cid=RSSfeed_DDJ_All

Original comment by jwl...@gmail.com on 17 Oct 2010 at 8:06

[GoogleCodeExporter]

Dejo también esta librería que se cita en el artículo anterior

http://www.codeproject.com/kb/library/dynobj.aspx

Original comment by jwl...@gmail.com on 17 Oct 2010 at 8:11

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 18 Oct 2010 at 5:40

• Added labels: Phase--1
• Removed labels: Phase-0

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 18 Oct 2010 at 5:57

• Added labels: Phase-0
• Removed labels: Phase--1

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 20 Oct 2010 at 6:39

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 29 Oct 2011 at 12:42

• Changed state: Postponed

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 11 Oct 2013 at 5:28

• Added labels: Phase-1
• Removed labels: Phase-0

[GoogleCodeExporter]

Original comment by Lince3D@gmail.com on 25 Apr 2014 at 11:47

• Added labels: Phase-2
• Removed labels: Phase-1