Re: [Radiator-devel] update

[Tim R. <ti...@ga...>]

On Mon, 19 Aug 2002 08:45:43 -0400
Patrick Mahoney <bo...@in...> wrote:
| > The Win32 PluginInfo constructor (where the calls to LoadLibrary and
| > GetProcAddress are located) will try to find the plugin_enum function.
| > If it does, it calls it to find what modules are supported; if not, it
| > assumes the plugin supports one module with the same base name as the
| > DLL.
| 
| This is WAY too complicated... It doesnt have to be! Why dont we let
| the dynamic libs register the plugins they can create? Something
| like...
| 
| extern "C"{
| 	void init(){
| 		extern map< string, Module*(*)() > creators;
| 		creators["reader"]=create_reader;
| 		creators["writer"]=create_writer;
| 		creators["wavout"]=create_wavout;
| 	}
| }
| 
| Would it be simpler?

Part of the rationale of keeping track of which plugins are loaded and
export a given module is to allow the environment to maintain per-plugin
information.

For example, it's useful to be able to load and unload plugin .so's at
run time (e.g. if you're developing a plugin, you'll want the UI to
unload it so that you can recompile it). So the environment needs to
keep track of what plugins are loaded, and how and when to unload them.

Another thing: we may want to expand beyond the create()/plugin_enum() 
(better to rename create() to plugin_create() for consistency?) to, say,
having .so's give the environment Plugin objects. Maintaining per-plugin
information gives us more flexibility.

| > | Another point... Each plugin is statically linked with the
| > | environment.lib library. Would it be worth it to make all the plugins
| > | share one instance of this library?
| > 
| > Yes, it probably would. Options are:
| > 1) Turn the environment into a DLL and have the plugins and UI reference
| > it
| > 2) Export the environment functionality from the UI
| > 
| > I think (2) sounds best. On Windows the plugin DLL can import from, say,
| > radiator.exe; I'm not sure of the Posix situation but I think it's
| > simpler there.
| 
| Hmmm... I dont understand what would mean in option 2)... Could you
| explain?

Plugins could either (1) call Environment:: member functions in a shared
DLL, or they could (2) call the implementation in the UI executable.

-- 
Tim Robinson <ti...@ga...>