Re: [boost] [SoC] Interest of a plugin library

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-03-19 11:27:33

Vladimir's ideas below are good ones - and things I've looked at. Most of
that functionality was directly used in the previous version of
Boost.Extension. With the current version though, I elected to make that
behavior all optional. As such, I've attempted to "make the common case
fast", by making the code as simple as possible for the most common uses of
the functionality, while making it possible to extend the library to cover
all of the areas mentioned below. The functionality below could be added
without needing to modify the current classes at all - just by adding new
helper classes. Since each factory can include arbitrary data with it, the
items below would not be difficult.

The previous version of the library handled dependencies between classes
directly - a class could declare that it could not be instantiated unless
certain other classes had already been instantiated. I decided, however,
that often this overhead is unnecessary and unwanted. As such, I refactored
it in such a way that the user can use arbitrary ways of determining
dependencies between classes, if they would like.

For instance, each class that we want to register could require that a
"registry" variable be passed into its constructor. It would then declare
that it had been created, and declare its capabilities. The destructor would
remove it from the registry. Thus, the registry would have no dependencies
on the other classes in Boost.Extension, and the other classes in
Boost.Extension would have no dependencies on it.

I've begun creating such "convenience" functions and classes that help with
common tasks - such as finding all plugins in a directory (and optionally,
it's subdirectories - it provides an argument that determines how deep to
look). The header files containing these functions can be included if the
user wishes to use the functionality - since this is a header only library,
there is no overhead whatsoever from them if they are not included. I
wouldn't mind having quite a number of such "convenience" headers.

Another possible "convenience" header would provide functionality for
automatically opening and closing a linked library. It could keep track of
the number of references into a linked library (i.e. how many factories
currently point refer to it, and how many classes have been instantiated
from it). When that count falls to zero, it would automatically close the
library. In addition, even the factory classes could be inherited from to
add more advanced functionality.

My primary goal here is to avoid creating a "framework". I don't want to
require the user to change the structure of their program in order to use
this functionality - it should easily fit into existing programs. I also
want to make sure that the library doesn't introduce strange issues when
multithreading. For this reason, all classes behave basically like you'd
expect from simple classes - they have no static data, and no static data is
required to use them. Factories can be created and used in different threads
as long as the user code (constructors etc.) can be used in multiple threads
(i.e. the functions are reentrant).

My previous attempt required the user to modify any classes that they wanted
to use as plugins if they wanted to track dependencies between them (if they
had no dependencies, no modification was necessary). The current version
does not require this. I want this library to work with existing code in a
natural fashion.

To answer Vladimir's questions more directly:

1 - All of the functionality that you proposed is possible, and would
probably best be implemented in "convenience" headers.
2 - I would love to have more help. However, if you wish to do this as part
of Google SoC, You'll have to find out the policies on multiple people on
one project, and discuss it with Mariano - since he is writing up the
proposal. If you could find a part of the project that was completely
separate from what Mariano proposes, perhaps you could propose it
separately.
3 - This library could be used as the basis for a "framework for services",
as you propose. In fact, part of the "convenience" headers could create such
a framework. But I do not want to make the library itself a "framework for
services".
4 - Your English was all very understandable. You don't need to apologize.

Jeremy

On 3/18/07, Vladimir Volod'ko <ustas_at_[hidden]> wrote:
>
> Jeremy Pack wrote:
> > Did you check out the code that I put up at
> > http://sourceforge.net/projects/boost-extension/? I'm currently working
> on
> > the documentation and unit tests for it (there are a few unit tests in
> it
> > already). It should run on OS X, Windows and *nixes.
>
> Hello!
>
> I'm very interesting in such library for my project and would like to
> help. Sorry for my English I'm not a native speaker.
>
> > I actually work for Google, so I can help out with SoC.
>
> > I really would not mind assistance with the library - this is only one
> of a
> > few projects that I'm working on in my free time. I'm especially
> interested
> > in any new ideas.
>
> > The library needs:
>
> > 1 - More unit tests
> > 2 - Performance analysis
> > 3 - Good documentation
>
> I really want to help with it.
>
> > I've thought of the following possible extensions for the library:
>
> > 1 - A mechanism for, optionally, automatically closing linked libraries
> when
> > they are no longer needed.
> > 2 - An option to not use RTTI, which is currently required (there are
> > various ways to do this - there have been suggestions to use some of the
> > features in Boost.Serialization, and there are various slightly hacky
> > techniques for it).
> > 3 - Other bits of expanded linked library functionality.
>
> > I built very full featured versions of the library earlier, but decided
> in
> > the end that a very clean, extensible interface was more important. So I
> > started from scratch about a month ago, resulting in what you see on
> > Sourceforge.
>
> > What features do you think are important?
>
>
> Here is requirements for my project's plug-in system (actually, it is a
> framework for _services_):
>
> 1. Locate and load plug-ins at start.
> 2. Load and unload plug-ins dynamically.
> 3. Track and resolve dependencies between plug-ins.
> 4. Plug-ins can add services and/or resources to service registry when
> loaded and remove them when unloaded.
> 5. One can ask list of registered services' identifiers with concrete
> name or satisfying custom condition.
> 6. After that one can acquire service by identifier.
> 7. If requested to unload plug-in is marked as removed and its services
> are removed from the registry. Plug-in does unload when all its services
> are released.
> 8. It is possible to register services without loading plug-in's dynamic
> library. Framework will load the plug-in on demand.
> 9. There can be many plug-in loaders in the framework also registered as
> services.
>
> My attempt was to mimic OSGI ( www.osgi.org/ ) bundles. Have you any
> ideas about it?
>
> Vladimir Volod'ko
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>