Re: [boost] GSoC: "Boost.Extension and Reflection" library [plugin]

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-06-04 16:30:12

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_at_[hidden]> 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              #
> ###################################
>
>