Re: [boost] RES: Log Lib!

Subject: Re: [boost] RES: Log Lib!
From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2012-01-03 17:09:12

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
>
>
>