Individually, many on boost have expressed the need for logging, application system, process management and plugin system. I think "generally useful" means boosters would want four separate configurable but easy to use library proposals rather than one mammoth proposal. Each library should be able to handle almost any task sent its way but still convenience functions, objects whatever that handle the 90% of use cases. Logging we have one just need yours build on top. While competitive libraries are welcome in Boost the results of acceptance and voting has been to the contrary. Application System: I don't know if yours is written but if not the POCO C++ libraries have one one that follows the boost license but unfortunately not a part of boost and needs revisions to use more boost libraries instead of their dependent POCO libraries besides stupid MFC class and function naming conventions. Boosters have been rejecting processing management libraries for as long as they have been screaming to have it. The odds are stacked against you. You may want to look at past failed attempts and the reasons why they were rejected. Collaborating in a team may work here where past attempts failed. This is desperately needed for the construction of tools such "automatic compilation and loading of shared libraries upon file change" or "dependency tracking/management". Tools arguably essential for the present and future success and competitiveness of Boost and C++. Once again POCO's C++ libraries provides this with the same need for changes. There may have been between 4 and 6 requests for comments on boost plug in systems in the past year. None have yet became proposals. Once again POCO C++ libraries provides this with the same need for changes. I am not advocating POCO C++ just highlighting much needed and welcomed additions to Boost. I am in the minority here but I would rather have 90% of something than 0% of nothing. For me, imperfect creations are welcome in Boost and not in the standard since I think of Boost as a proving ground. Others and the majorities standards are much higher than mine when it comes to C++ code. On 1/3/2012 4:33 PM, Renato Forti wrote:
My plan is build some thing like this:
* Log System
* Application System (Windows Service, Unix Daemon, Usual Application)
->Process Management
* Plugin System (services model) : late bind dynamically extensible that will provide modular applications like an service that can be loaded in application container.
Than a developer that need create a server, for sample:
Extend for boost::application::server and in this it use boost::log .
To create service (modular application) he extend of boost::service to create a service and plug this service in runtime on boost::application::server. Application can be configured using Boost.Program_options for sample.
What do you think?
Do you think that "this" is very specific, and violate: " The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost.
Thanks