Subject: Re: module manager
From: Hubert Figuiere (hfiguiere@teaser.fr)
Date: Wed May 02 2001 - 01:56:29 CDT
According to Paul Rohr <paul@abisource.com>:
> 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.)
Switching to C++ linkage for module is not a good idea, unles you plan to use
an ORB which we do not have in a cross platform manner.
> 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.
For this I just can suggest a method RecognizeMetadata() that is virtual and empty
that platform implementor are free to implemen if they wish (BeOS also has such
a thing). What shall we pass to the method is another question.
Hub
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:00 CDT