Subject: Re: module manager
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Tue May 01 2001 - 20:18:54 CDT
Hi Paul,
>Some stuff to think about:
>
>1. So far, your thoughts about the discovery API sound plausible, and I'll
>be interested to see what you wind up with. The trick is, as always, to
>know that you can call into a static entry point to bootstrap a process of
>locating wider-bandwidth APIs that you can call. Starting out with a
>lightweight C interface feels right, but I don't have a feel for when
>switching into C++ makes sense. (For example, see #7 below.)
Discovery is a beast that I don't want to touch right now actually. It's a
bit advanced and I just don't have the time. Others are encouraged to come
up with something, should they feel the need exists. Or if I get the urge...
Anyway, the reason for a C interface and not C++:
Consider this function compiled by GCC vs G++ (w/o extern "C")
int abi_plugin_init (void);
C-linkage: abi_plugin_init
C++-linkage: abi_plugin_initFasdwq21332119`12ALLYOURBASEAREBELONGTOUS
So for our resolveSymbol() function, it's we can assume that with
C-linkage(or extern "C"), "abi_plugin_init" means abi_plugin_init. I have no
idea how we'd handle C++ linkage/name mangling, esp. in an XP and
cross-compiler manner (or even if we'd want to). This was my only concern.
>2. You may want to move consider moving the versioning down a level. If
>you only version at abi_plugin_* layer, then each time one of the
>plugin-specific interfaces changes, you'd need to rev the enum. For
>example, if version 1 is as you describe, then you'd need to bump up to
>version 2 to detect the difference between ABI_PLUGIN_IMP and
>ABI_PLUGIN_IMP2. (Good up-front design can reduce the need for these kinds
>of versioning woes, but they never disappear entirely.)
This is totally feasible. Right now, we don't pay any attention to the
versioning info right now, but we should. But again, this is more
discovery-based. All I'm assuming is that if we pass 0.7.15 to a plugin
which only supports 0.9.0, it will barf (i.e. we only care about the abiword
version, not a specific interface version).
>3. Do you plan to allow a single module (ie, one DLL, or SO) to expose
>multiple instances or interfaces? For example, imp_MSWord and exp_MSWord
>will both want access to wv, so one stable way to package that would be to
>ship the whole glob -- imp plus exp plus (perhaps) wv -- as a single
>module.
Yes, this is already possible. plugin_init could register both an importer
and an exporter, for that matter. It's not sophisticated to say "load the
importer but not the exporter." Again, that would be more discovery-based.
>4. As a variant on #3, this may be how we'd want to access a thin wrapper
>class which accessed platform-specific functionality to do, say, image
>imports. I'm not sure this is necessary, though, because in that case you
>could just compile it into the binary.
You could compile in filters too. But why do that if you don't have to with
a decent API? I'm working on a new image framework... you'll see :)
>5. As another variant on #3, would you need to package all of the
>XML-derived imp/exp classes into the same module to avoid duplication of
>the
>parent class?
Sure, this'd be great. Wouldn't it also be doable that we leave the XML
importer in the binary, and have these subclasses link against that? I'm
assuming that we probably don't want to turn these 3 filters into plugins:
TXT, RTF, ABW
The reason I mention this is that TXT and RTF are essential for clipboard
and we don't want _any_ chance of these not being found.
>6. Are there any clever XP ways to avoid loading the modules just to query
>their capabilities? Ideally, we'd be demand-loading these modules to hold
>down our memory footprint, and having to load and unload them just to know
>what we have to choose from could get expensive, depending on how large the
>modules are, how smart the loader is, where those entry points are
>"physically" located in the module, etc.
We can probably do this. A better approach would be an XML (or other)
description file, explaining cross-plugin dependencies, what a plugin
exports, etc...
>7. I'm not familiar with the relevant patterns here, but off the cuff, the
>creator/child pattern sounds fine. Moving the static funcs out of the
>class
>sounds appropriate, and it might even be tempting to expose those as C
>entry
>points instead. This could add some additional complexity if those methods
>need "friendly" access to the impexp class itself. However, it does have
>the advantage of reducing potential brittleness in the Creator interface
>definition (if you need a new method, you don't have to define a whole new
>class, just look for the extra entry point). For example, we already know
>that Hub is likely to need additional impexp sniffers for Mac-specific
>creator/filetype pairs, and in the future we might need to augment those
>top-level APIs for other reasons.
This is totally feasible and desirable IMHO. The model/pattern is a good one
for this specific problem. We don't necessarily need a friend here, because
all the creator does is call 'new Createe(pDocument);' But it might make
sense to do so. On another note, Hub's stuff will almost certainly live
behind an #ifdef MAC though.
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:51:00 CDT