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@unipro.ru> 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