Sebastien, You can actually load all of the libraries that contain plugins at once, and then load whichever plugins you would like from them - you don't have to know which specific library it is in. However, there is currently no mechanism to know which libraries are available. Possible methods include: 1 - Put a common extension on each library (in the examples, for instance, every library ends with .extension - which is completely arbitrary), and then use Boost.Filesystem or some other method to iterate through a directory (and, optionally, it's children). This method was implemented earlier, but is not currently part of the library. 2 - Have a config file, as you mention, that lists the shared libraries and their respective loading functions. This is one area where I felt that the user could go into the specifics, instead of the library - but I am putting in so-called convenience headers that can be included if the user wants some of these types of functionality. We could put something similar to what you propose into such a convenience header. It would certainly be a common use case. Jeremy On 6/3/07, Sebastien Binet <hep.sebastien.binet@gmail.com> wrote:
Hi Jeremy,
As I mentioned, I put together a release - it can be considered the starting point for the SoC project.
The "registry" class has some bugs with library unloading. The API for it is all in place though. Refer to the registry example to see how to use it. That class will change a bit underneath to maximize the library unloading possible - but the API should stay the same.
Refer to the HelloWorld sample for the simplest use of the Extension library.
Refer to the MultipleInheritance sample for a complicated use of the library. Note: multiple inheritance across shared library boundaries is messy, and I only made an example of it to show that the library can handle complicated inheritance hierarchies involving dynamic and static linking. Note 2: On Unix systems, you may have to change your LD_LIBRARY_PATH for the multiple inheritance example.
The recommended way to use the library (for now) is to download the sandbox SVN repository at svn.boost.org. Then you can sync it later to pick up new changes.
You may also download just the Extension library at: http://svn.boost.org/svn/boost/sandbox/libs/extension/Release%205-29-07.zip
It seems to me your library is missing an interesting feature: loading plugins on demand. Right now it seems you have to know in advance in which library a component resides to load that library, and eventually load the requested component.
I guess a little "manager" class, filled from a boring ASCII file (or whatever) containing a list of [component-name] : [library name] would be interesting. The factory_map would go the plugin manager when somebody says: IMyInterface* = gimme<IMyInterface>( "MyConcreteClass" );
The ASCII file(s) could be automatically constructed at build time or carefully handcrafted.
HTH.
Cheers, Sebastien. -- ################################### # Dr. Sebastien Binet # # Lawrence Berkeley National Lab. # # 1 Cyclotron Road # # Berkeley, CA 94720 # ###################################