nebmods API

[Ben]

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.

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. :)

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. I'm not exactly 
sure what you mean by "deep memory management", 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.)

4. I don't understand this one, so I can't say much about it.

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 code-snippets and syscalls). I've implemented 
> this in-house in the module for now.
>
> #3 requires rather careful thought and planning. What's a reasonable 
> maximum length for host_name variables? I've never seen one that 
> approaches 30 chars, while the alias field could well go up to 40 
> chars or so.
> This change would have a pretty huge impact, so I think I'll just 
> implement it with conversion-routines inside the module instead, 
> although some of it should be taken care of with the implementation of 
> indexed table lookups. For example, having indexes (as opposed to 
> object names) to objects that doesn't require argument lines or other 
> kinds of options would be a tremendous memory save and simplification.
>
> #4 can be solved in pretty much only one way as I see it. The most 
> flexible, easiest to implement and coolest method would be to have 
> modules inject parameters into an array structure as such;
>
> typedef struct config_var {
>   char *var_name;
>   int flag;
>   void *(*func)(int, struct config_var *, char *);
> } config_var;
>
> struct config_var static_cfg_vars[] = {
>   {"cfg_dir", 0, (void *)handle_cfg_dir_var},
>   {"log_file", 0, (void *)handle_random_cfg_var},
>   {NULL, 0, NULL}
> };
>
> config_var *cfg_vars = (config_var *)&static_cfg_vars; /* set default 
> */
>
> /* pseudo-code */
> (iterate until we hit the NULL stop)
> match cfg_vars[x]->var_name with cfg input
> /* run the proper function. pass the cfg_var entry so all extras are 
> sent as well. Very "future"-compatible */
> cfg_vars[x]->func(x, cfg_vars[x], cfg_input_string);
>
> This way all a module would have to do would be to copy the cfg_vars 
> and add entries before the pointer is sent to the parsing routine. 
> Each object type would have its own version of this so as to 
> facilitate most (or all) of the things people would want to do. 
> Naturally, this could be applied to other stuff (macros?) as well in a 
> similar way.
>
>
> Thoughts? Comments?
>
> -- 
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Lead Developer
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click