> Speaking for myself.....
>
> 1. I don't really care. It may not be clean as it is today, but it's not
> so hard either. Cleanliness is all well and good, but I'm chasing bigger
> fish.
>
Perhaps so, but it'd be a rather simple fix (although wasted if Ethan
doesn't like it), so it's in the "low-hanging-fruit" category.
> 2. Again, I don't really care, but this time it's because I'm using the
> nagios-db module. Perhaps if I was using other modules I would care
> more.
>
True. But for some modules this could be vital info. Adding redundant
code goes against my sense of stylishness.
> 3. If there's anything the history of programming should tell us, it's
> that making fixed-length buffers for strings is a bad idea. There will
> always be an exception. I don't see anything wrong with prefixing the
> strings with their length. This takes care of the networking issues
> quite well. At least, it always has for my projects.
Yes, but it would mean sending several times for a single object, as
opposed to send(sock, &host, sizeof(host), );
> I'm not exactly
> sure what you mean by "deep memory management",
That you have to enter the struct itself to be able to manage it as a
whole, or memory will leak. Look in the code and you'll see what I mean
free(host->name); free(host->alias); free(host->this_and_that); free(host);
> but make religious use
> of some helper functions and you should be fine. (Yes, there will be a
> lot of mallocs and frees, but last I checked these were nowhere near the
> top of the performance bottleneck list.)
>
True, but they are notorious for causing memory leaks.
> 4. I don't understand this one, so I can't say much about it.
>
Quite simple really, although the code isn't exactly "Programming 101".
Each configuration directive has a function handling it and an arbitrary
amount of flags associated with it. As such, it's trivial to add
keywords to the list and the keyword handling functions could look at
one of the flags to get the variable and then at another flag (cfg_var
offset?) to look up what variable to assign to the value. A simple way
of getting rid of redundant code-snippets and if() else if() in
cfg-parsing. It also inspires better exception handling, since it
doesn't have to be duplicated ad nauseum.
> On Feb 9, 2005, at 12:55 PM, Andreas Ericsson wrote:
>
>> So...
>>
>> I've taken up hacking on a redundancy/loadbalancing module (old news)
>> and it's starting to come together quite nicely. Unfortunately, I've
>> run into a couple of very irritating problems which had to be worked
>> around in sometimes less than optimal ways.
>>
>> 1) There's no simple way to #include everything one needs to make full
>> use of a loadable API or select parts of it that are necessary.
>> Prototypes are scattered wide through the header files, each .c brings
>> in its own extern'al ones, and no global vars are
>> 2) Object config filenames are thrown away after they are parsed
>> inside the function that calls the parser, so they never make it global.
>> 3) (I've posted about this before) Most string variables are stored in
>> flexible-length pointers, making it seriously difficult to handle as
>> network data. It also adds a necessity for deep memory management and
>> an unseemly amount of malloc()'s and free()'s. It also makes it
>> completely impossible to store objects.cache in a binary file for
>> ultrafast parsing by the CGI's.
>> 4) There is no way for modules to help Nagios handle more config
>> options the way Apache does.
>>
>> These problems require "design intervention"
to a greater or lesser>> degree so I won't be starting on hacking patches until I've heard from
>> Ethan on this.
>>
>> Solving #1 would actually make the package nagios-devel useful. The
>> manpage nagios-neb(3) should ofcourse see the light of day, if only
>> with a list of prototypes, exported functions and available macros. In
>> reality, it's all any competent programmer needs to start hacking.
>>
>> Solving #2 proved to be a one-hour exercise in coding (done properly
>> and without redundant c
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]