At 04:35 PM 5/1/01 +0100, Tomas Frydrych wrote:
>The module manager looks great Dom. 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.
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
I haven't seen any discussion of the specific kinds of discovery APIs we'll
eventually need for modules of a given type, so I suspect that those
problems are still ahead of us, at least.
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
Ditto for the sets of localization tables hardwired here:
abi/src/wp/ap/xp/ap_Menu_LabelSet.cpp
abi/src/wp/ap/xp/ap_Menu_LabelSet_Languages.h
abi/src/wp/ap/xp/ap_Toolbar_LabelSet.cpp
abi/src/wp/ap/xp/ap_TB_LabelSet_Languages.h
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.
Paul
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?
