Dom,
Thanks for the update. I think I see where you're heading and will comment
more when your plans mature.
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.)
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.)
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.
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.
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?
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.
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.
OK, that's more than enough for now.
Paul
