[Gtkradiant] Plugins and Modules

[Hydra]

Ok, so I'm creating a set of plugins that have a common interface but they
are *NOT* a required modules (i.e.  it won't appear in the
g_requiredModules[] table, and thus won't have it's function table
accessable by the core of radiant).

Within main.cpp (of radiant itself) I need to call a function from any
plugin that provides that function and other plugins must also be able to
call the function.

e.g.

I have two plugins:  "plugina" and "pluginb", they both provide functions
for an interface called "foo module".

The both provide the function DoSomething().

Within radiant's main.cpp (or elsewhere in the core) I need to call
DoSomething().

In addition, OTHER plugins must also be able to call the function
DoSomething()

I also don't care if no plugins provide DoSomething()

Now, what I can do is make a function which checks all loaded plugins,
requests the interface and checks to see if that plugin supports that
function and if they do call it.  But the amount of code required to do that
is c-c-c-crazy, not even mentioning the amount of memory it uses by having
to request the interface table each time I want to call it.

I have a few thoughts on how to fix this,  it'll require some reworking of
the pluginmanager, but I do belive it will be much better for it and can fix
a few things at the same time.

Basically, it involves storing ONLY A SINGLE copy of each plugin's interface
function table when the plugins load, this is instead of the current method
of allocating a function table for the required modfiles in
g_requiredmodules and using a common set of FAST functions for the core AND
the plugins to use..

The main use for this is having one or more CORE modules that provide the
same interface and set of functions, e.g  two (or more) entity loaders, or
two (or more) vfs systems.

In sorting this out I can probably also sort out the "VFS table request
scheme BLOWS" message too...

If we were to rework the plugins so that each plugin stores a list of
functions
that it provides as a list of strings, then when a plugin loads we could ask
it
to fill a list of function pointers for each of the functions that we know
about, rather than asking for a table of pointers each time.  This would
then
allow us to change this list of functions without requiring plugins/modules
to be
recompiled.  this then negates the problems that we have with different
versions
of the function table.  Obviously we could not change the values passes as
parameters for these functions, but we *would* be able to add additional
parameters to those functions withing having to have a module re-compiled.

This would work wonders for plugins that are not maintained by their authors
and each upgrade of radiant would not break all of it's plugins.



If you have any thoughts on this please let me know,  I notice that the
imap.h says the way it provides access to Map_LoadFile() in the map module
is experimental and now I see why...

Hydra

Here's a code snippet of what I currently have to do:

pluginmanager.cpp: