#13 new plugin interface (xml params+ combined dll's)

[Chris Thomas]

The new direction for FusionSubsystem plugins is to
have a combined DLL of all the built in implementations
instead of separate DLL's for each and allow the
configuration of which implementation to do done from
the xml configuration file used to load the plugins.

CURRENT SITUATION

The current situation is that if you want to use
OpenGL, you tell fusion to use the dll you compiled
OpenGL fusion subsystem into and it calls the
GetInstance(Fusion &) method which would return an
object of the IGraphics type, derived into an OpenGL
implementation, if you wanted to try your new
implementation of OpenGL, or DirectX graphics, you
would compile it, drop the DLL into the directory with
all the other fusion dll's, update the xml config file
to load your DLL as opposed to do the one it was
previously supposed to. Then fusion would load it, if
the plugin was 100% compatible, then it would work
without issue.

=============================
++ Issue of Trust
At the moment, fusion subsystems are not queried as to
whether they are compatible with the part of fusion
they are being loaded into, so currently, it's more
than possible that the Network plugin can be assigned
to the Graphics pointer inside the Fusion object, this
is because all fusion subsystems derive from
FusionSubsystem, therefore they all share a common base
class. More error checking and validation code is
therefore needed to plug this hole.
=============================

FUTURE SITUATION

The future situation is going to allow the current
situation to work like normal, but extend it into a
more flexible and probably overall better approach.

The idea is to combine plugins together, so rather than
have a dll for OpenGL and DirectX, you'd have a
libGraphics.dll plugin, which would contain both
subsystems, which would be chosen, by using a param
attribute inside the block of XML assigned to load that
dll. Swapping implementations from OpenGL to DirectX
then becomes a simple issue of destroying/cleaning up
the old object and using the same dll, which is already
loaded, to create an object of a different implementation.

examples

<subsystem name="graphics" module="libGraphics.dll"
param="ch:OpenGL, DirectX, OpenGL" />

<subsystem name="network" module="libNetwork.dll"
param="ch:PThread, Win32, PThread" />

first part of the xml is unchanged, but the added param
attribute allows specification of a particular
subsystem to be loaded from a list of possibilities.

ch:OpenGL, DirectX, OpenGL

ch: means chosen implementation

what follows is a comma delimited selection of strings,
the first token is the chosen implementation, the
following tokens are the values that are available.
Choosing DirectX would involve

ch:DirectX, DirectX, OpenGL

This new system would simplify the plugin system
greatly by only having one plugin per subsystem, plus
however many custom plugins written by third parties to
overload the built in plugins, it would also help with
broken plugins, in which a plugin provides multiple
implementations, it could switch to the next
implementation to attempt to run with that (perhaps the
implementation isnt compatible with the
hardware/software in theoperating system?)