...

So I'm writing this email because I want to know if there is interest in the community of a project of this type, because I want to participe in Boost/SoC and if it isn't interesting I will try to find some other idea.

I think it's a plausible idea although there has already ben some proposal in this area.

http://lists.boost.org/Archives/boost/2007/02/117030.php

http://sourceforge.net/projects/boost-extension/

That said, it might make it more reasonable to bring things to completion within the SoC time frame, so I wouldn't rule it out at this point.

First, thanks for your answer. I didn't know the existence of that library... I think that it is very similar to my idea.. so.. maybe someone with more experience in the boost community could give me advice about how to apply to improve that idea? In any case, please do consider applying -- there are lots of possible

projects and folks are definitely willing to help you get something that will work.

I really want to apply, but I want to write a good proposal according to the feasibility of the project.. so if there is in the list anybody that could me help giving advice of what should be done to improve that library, or to write other, please contact me. Thanks!

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. 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'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? Jeremy Pack On 3/13/07, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:

Mariano Consoni wrote:

...

...

I think it's a plausible idea although there has already ben some proposal in this area.

http://lists.boost.org/Archives/boost/2007/02/117030.php

http://sourceforge.net/projects/boost-extension/

That said, it might make it more reasonable to bring things to completion within the SoC time frame, so I wouldn't rule it out at this point.

First, thanks for your answer.

I didn't know the existence of that library... I think that it is very similar to my idea.. so.. maybe someone with more experience in the boost community could give me advice about how to apply to improve that idea?

In any case, please do consider applying -- there are lots of possible

...

projects and folks are definitely willing to help you get something that will work.

I really want to apply, but I want to write a good proposal according to the feasibility of the project.. so if there is in the list anybody that could me help giving advice of what should be done to improve that library, or to write other, please contact me.

I'ld be happy to help here. I'm using a slightly modified early version of a similar library (initially written by Vladimir Prus, here: http://tinyurl.com/3xeqzr) for quite some time now and I think we need something related in Boost! A good starting point would be an analysis of the existing libraries to be able to define a suitable API and the related functionality (Jeffs mentioned boost.extension already containing a good overview). I think the required effort to write such a library makes it a good candidate for SoC.

Regards Hartmut

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Comments below, On 3/13/07, Jeff Garland <jeff@crystalclearsoftware.com> 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.

I actually work for Google, so I can help out with SoC.

Just to clarify, would Mariano apply to Boost or Google as the mentoring org in this case? I suspect the answer is that it could be either way, except that you aren't a Boost mentor so any help you give would be 'unofficial' if the work was done thru Boost.

He'd need to apply to Boost. As for the project, I wonder if we should consider a project that has the

specific intent to bring the library completed, up to Boost standards, and reviewed within the SoC time period. I don't know if that's feasible (haven't looked at the lib), but I imagine we could make review queue accommodation's. It would be something of a hybrid in that it wouldn't be entirely the work of the Mariano, but it might be a different approach to getting SoC projects into Boost faster. We have the BigDecimal library in the sandbox which I believe could similarly be picked up, finished off and submitted in short order.

Jeff

I believe it could be brought up to Boost's standards in the time period. I would appreciate any criticism on how complete the code itself seems (for instance, is major important functionality missing, or are any parts in need of a major overhaul). Jeremy

Mariano Consoni wrote:

...

He'd need to apply to Boost.

Thanks to the community for the interest in my proposal. Now I think it would be interesting for me to know what the community thinks about different ways of approaching my proposal. Surely Jeremy has a lot of information for that, and it would be good to review that with the community.

I'd suggest you carefully study the details of the state of the extension library and make a detailed proposal. You could discuss this on the list, privately with Jeremy, or however you'd like to handle it.

I like the idea of helping to complete and improve Jeremy's work.. Is possible that Jeremy become a mentor? I think that a co-mentoring with someone from Boost could be very productive.

I'm afraid Jeremy cannot be a Boost mentor as we require the mentors to be a Boost library author. That said, there would be nothing that stops Jeremy from helping a student with technical issues, which he sounds willing to do -- he just wouldn't be doing the evaluation of success or failure of the project. In any case, I'm sure one of the Boost mentors would be able to help with this library. Jeff

...

...

I like the idea of helping to complete and improve Jeremy's work.. Is possible that Jeremy become a mentor? I think that a co-mentoring with someone from Boost could be very productive.

I'm afraid Jeremy cannot be a Boost mentor as we require the mentors to be a Boost library author. That said, there would be nothing that stops Jeremy from helping a student with technical issues, which he sounds willing to do -- he just wouldn't be doing the evaluation of success or failure of the project. In any case, I'm sure one of the Boost mentors would be able to help with this library.

I'ld be happy to to that.

Excellent, thank you very much. I've just interchanged some emails with Jeremy and I'll see a bit the extension library and start to write a proposal with his advice and help. I'll send a message to the list again when I finish this first review. Thanks again! Mariano

I want to suggest Robert Ramey as a mentor (if he agrees of course), because boost::serialization already has some mechanisms for plugin library in place.

I agree - we discussed this in a thread a few months ago. Robert's help would be appreciated, especially for removing the RTTI requirement from the library. He already pointed me in the right direction - I just haven't gotten the chance to work on implementing it yet. However, there are places in the code where I currently use a python script to generate some redundant template code - Hartmut Kaiser's preprocessor library would probably come in quite handy there and in a few other places. A number of items in my "to do someday" list involve using the preprocessor and template tricks. Either of them has knowledge that would give Mariano (and me of course) great material for the library. Jeremy

On 3/13/07, Robert Ramey <ramey@rrsd.com> wrote:

I've looked at this proposal a little bit. I was expecially curious how it managed to do this totally within a header with not static objects. I had been unable to do this.

It took me a while to figure out. I probably wouldn't have submitted the library without this feature - it is one of the primary features that sets it apart from the other plugin libraries that I was able to find. Looking at a tiny bit more carefully, it seems to be that it presumes

that the possible "plug-ins" are listed ahead of time. I'm not sure what the all the implications of that are. But it would preclude shipping an add-on DLL to be used by an existing program.

I can see how my examples might give that impression. It does NOT require that the plugins be listed ahead of time. It does require that some sort of interface (base class) be defined ahead of time. But shipping an add-on dll to be used by an existing program is the primary goal of the library. I think one of my examples shows that pretty well - look in the examples folder for the hello world example. The "existing program" (main.cpp with a header of word.hpp) only knows about the word class. The "Add-on DLL" (hello_world.cpp, which also uses word.hpp) is the only entity that knows about the hello and world classes. But the "existing program" can use them, because they are both derived from the word class. I will attempt to have decent documentation up with the rest of the code very soon. Thanks to all of you who have taken the time to look through the library anyway! This isn't necessarily a criticism, but its clear to me that this is

a "different thing" than what is part of the serialization libary.

The extended_type_info component could use a "construct from id" function. The serialization library doesn't need it but I thought it make make the component more useful. The details turned out to be problematic. But recently a possible way to do this has occurred to me. So maybe something will happen someday in this regard.

Implementing this for non-RTTI wasn't all that hard as I remember. It did require a fair amount of code shuffling which resulted in breaking out extended_type_info as a separate component.

The current version depends upon static objects to register themselves in a global table so they don't have to be "pre-registered" by the programmer. This is convenient - and its what people insisted on - but I think this is the root cause of some of difficulties which occured (hopefully resolved in the HEAD) with the dynamic loading/unloading of DLLS.

That is what I expected - I doubt that there is a way to do the extended type info without static objects unless you require a bit of extra work from the user. The serialization library lets one select the typeinfo

system he want's a particular class to use. The common one is RTTI. However, one based on the specified EXPORT name is also implemented. There is a test which demonstrates that the different systems inter-operate. So it might be interesting to see if this method would/could be used as another variation of extended type info.

This would be very useful for plugins - allowing a choice between the systems would definitely alleviate a lot of people's concerns. I didn't spend a huge amount of time looking at it

so feel free to take these comments with a grain of salt.

Robert Ramey

I don't expect anyone to take a huge amount of time looking at it yet - I put it up to find out if anyone had suggestions for API improvements or additional features. Thanks for looking over it! Jeremy Pack

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

On 3/19/07, David Abrahams <dave@boost-consulting.com> wrote:

on Mon Mar 19 2007, "Jeremy Pack" <rostovpack-AT-gmail.com> wrote:

...

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 don't think "non-intrusive framework" is an oxymoron.

I suppose I overgeneralized! Sorry about that - I use and build frameworks myself. I just felt that in a library, especially one designed for Boost, it would be better to make it as flexible as possible.