Subject: Re: module manager
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Tue May 01 2001 - 12:15:08 CDT
Hi Tomas,
>The module manager looks great Dom.
Thanks a lot! I spent some bit of time on its design. I hope that it's
adequate for our needs, or at least extensible enough so that it can meet
them. I have to fix up a small bug preventing this from compiling on some
platforms (silly private destructor :-) but on the whole, it should work
pretty much out-of-the box XP. I'm pleased!
>Now, should we have some
>mechanism for automatic loading of modules? Perhaps we might
>say that all modules are to be located in AbiSuite/modules, and
>they have to follow certain naming convention, e.g., libAbiMod*. On
>startup we would load all such modules available.
This is exactly what I was thinking. We should have the App load some set of
modules/plugins on startup. These would be contained in some directory on
disk (suggestions can include AbiSuite/modules, AbiSuite/plugins
AbiSuite/plugins/0.7.15, ...) so we should probably should choose our
convention now. I'm in favor of AbiSuite/modules/version# but others may
hold other totally acceptable opinions. I'm flexible, so make your cases :)
Loading (at least on startup) will have to be done in a platform-specific
APP class. This is because we will need to do things similar to this
pseudo-code which involves some possibly platform-specific work (obtaining a
directory list, file extensions, etc...):
files=`ls libAbiMod*.so`
for file in files do
loadModule $file
done
The suggestion for using libAbiMod*.(dll|so|whatever) is great. I'm all in
favor of it. Dissenters please speak up now or hold your peace until you get
CVS commit access :^)
We'll also allow for runtime loading/unloading of modules from some sort of
dialog which can report all sorts of information about the plugin (i.e. our
XAP_ModuleInfo struct). I will put some more info/data into the struct, so
I'm looking for suggestions as to what we should have here.
The next step is to actually make some of our interfaces more easily
adaptable for use by plugins and then make said plugins. I'm suggesting that
we can start with impexp, possibly with the PalmDoc exporter or importer
since it's a relatively easy and small testcase. To do this, we'll need to
do some work in the ie_imp.cpp and ie_exp.cpp files to probably use vectors
for internal structure and have a "Register/Unregister" function for our
filters.
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:50:59 CDT