Subject: Re: module manager
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Tue May 01 2001 - 12:43:13 CDT
>I'm glad to see that we're making headway on low-level XP mechanisms for
>locating and loading modules. Could someone comment on which of the
>following kinds of dynamic loading these changes are intended to cover?
>
> http://www.abisource.com/mailinglists/abiword-dev/01/April/0704.html
Sure. What I've done is an extremely simple and totally generic module
loading mechanism. There are 3 requirements for its validity/usage:
int abi_plugin_register
int abi_plugin_supports_version
int abi_plugin_unregister
So, this would take care of cases #1 for you (Automatic, fixed entry points)
and #2 (Manual, at run-time, dlopen-style).
Now, if we want to get more fancy is another story. A discovery API would be
extremely useful and not a hell of a lot of work on the *plugin* side of
things, but would be more complex on the *Abi* side. Because I am a
simpleton, one might have:
typedef enum {ABI_PLUGIN_IMP, ABI_PLUGIN_EXP, ABI_PLUGIN_IMG,
ABI_PLUGIN_ENCODING, ...} ABI_PLUGIN_INTROSPECTIVE_TYPE;
ABI_PLUGIN_INTROSPECTIVE_TYPE abi_plugin_introspect ();
*as a first draft*.
>For example, the existing class factory for instantiating specific imp/exp
>implementations would certainly need to be refactored if we wanted to
>externalize all that logic. To make that kind of thing Just Work, we'd
>need
>to stop looking for a fixed set of classnames hardwired in static tables
>here:
>
> abi/src/wp/impexp/xp/ie_imp.cpp
> abi/src/wp/impexp/xp/ie_exp.cpp
Yes, see my previous post. I was thinking of the following
(non-introspective) example:
bool b = loadModule ("libAbiModPalmDoc.so");
... and deep down in the bowels of libAbiModPalmDoc.so it does:
IE_Imp::intance().registerImporter (new IE_ImpPalmDocCreator());
I'm thinking that we should have a creator/child mechansim here. I.e.
instead of RecognizeContents, etc... being *inside* of the impexp class, we
have another class responsible for those (currently)static methods and this
class also has the responsibility of creating valid instances of the
importer.
class IE_ImporterCreator
{
public:
virtual recognizeContents (...) = 0;
...
virtual IE_Imp * constructImporter (...) = 0;
}
class IE_ImpPalmDocCreator : public IE_ImporterCreator
{
...
}
>There are well-known C-based solutions for how to handle this kind of
>design
>problem, but I'm a bit fuzzy on what the C++ analogues, if any, should be.
I *think* that I have a fairly good grasp on what to do here. I'll work on
this some after I finish my imaging draft design (which I'll send it to the
list for validation/suggestions soon).
>PS: These changes are still on fire in Tinderbox -- something about
>inability to access a private destructor. Is anyone already looking into
>that, or are more eyes needed?
Mike Pritchett just committed a fix. Hopefully my (off-list) suggestion
works too, which would please me more.
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