<div class="gmail_quote">On Wed, Jun 29, 2011 at 2:50 AM, Andreas Ericsson <<a href="mailto:ae@op5.se" target="_blank">ae@op5.se</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div>On 06/28/2011 05:13 PM, Matthieu Kermagoret wrote: > Hi list, > > First of all, sorry for the delayed response, last month was pretty > crazy at work :-p > > On Mon, May 23, 2011 at 12:38 PM, Andreas Ericsson<<a href="mailto:ae@op5.se" target="_blank">ae@op5.se</a>> wrote: >> On 05/23/2011 11:37 AM, Matthieu Kermagoret wrote: >> Because shipping an official module that does it would mean not only </div></blockquote><div> [snip] </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>> For years it's been Nagios' > development team's policy not to include features that could be > written as modules. I liked it that way. > </div>Everything can be written as modules. The worker process thing will have the nice sideeffect that modules can register sockets that core Nagios will listen to events from, with a special callback when there's data available on the socket. This reduces complexity of a lot of modules by a fair bit. With worker-processes instead of multiple threads it's also trivial to write modules with regards to thread-safety, and potential leaks in worker modules (such as embedded perl) can be ignored, since we can just kill the worker process and spawn a new one once it's done some arbitrary number of checks. This is how Apache handles leaky modules and we could do far worse than using the world's most popular webserver as an example. There's also another thing. Mozilla Firefox has been accused of feature stagnation in the core since they let addon writers handle adding new features, and far from everybody uses modules. Google Chrome has taken a fair share of users from Firefox lately, partly because it implements some of the more popular modules directly in-core. Nagios has also been accused of feature stagnation, even though broker module development has flourished in recent years (nagios with modules is nothing like the old nagios without them), so it makes sense to add certain selected module capabilities to the core. <div> </div></blockquote><div> There seem to be two issues, I think, that are getting mixed here. I think the accusation of Mozilla Firefox/Nagios Core feature stagnation is a separate issue from putting things in core as opposed to making them a NEB module. The Linux kernel is a good example of tons of features existing in modules and not being included in the core, yet not having the feature stagnation problem. The difference between those and FF/Nagios is that the modules are included in the /distribution/ of the code and many are active by default. This has the major advantage that if someone doesn't like/need a particular module, it can be trivially removed. This helps performance tuning. etc. At the same time, it allows feature progression, by default. I think if this approach were taken, more modularization rather than hard coding things into the core, but including more widely accepted modules in the default Nagios Core distribution, that would keep everyone happy. That being said, I think placing the networking socket code into the core is completely reasonable, since it is such an essential part of the architecture. Although theoretically you could remove all networking from the Linux kernel and still run... Really, on that part at least, I think either way would work out fine. Just a thought, Adam Augustine </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div> </div></blockquote></div>