[Nagiosplug-devel] Kickoff for 1.5

[Andreas Ericsson]

Ton Voon wrote:
> Hmmmm.
> 
> On 9 Mar 2005, at 08:38, Andreas Ericsson wrote:
> 
>>> - consolidation of duplicate code
>>>   depending on what we learn from the above two, it might make
>>>   sense to develop a common code base to reduce code redundancy.
>>
>>
>> This is an area where much can be gained. The plugin devel api today 
>> isn't very useful.
>>
>> For spawning commands, there should be a function that takes as input 
>> the command line, and returns the output and return code of the 
>> command. This would accomplish much and get rid of a LOT of duplicate 
>> code in the plugins.
>>
>> For snmp, there should be a function that takes a snmp_auth struct 
>> (which needs to be invented) and a list of oid's to fetch, and then 
>> returns the values of those oid's in an array.
> 
> 
> Good idea. In the general case, common code base is a good goal.
> 
>> For argument parsing, the getopt_long function might be all good and 
>> well, but it's behaviour on various systems is undocumented (some 
>> break parsing on first non-option argument, other reorder nonopts to 
>> be last and just keep going).
> 
> 
> This is just plain wrong. We use getopt.c from the GNNU coreutils 
> project. We ignore any system implementations of getopt. If you find 
> something wrong, I'll be happy to accept a patch and I will also push it 
> upstream to the GNU coreutils project. But, without a patch or an 
> accurate bug report, I am taking your opinions with a huge pinch of salt.
> 

Didn't notice you were using an imported version, so my point is 
probably moot. I'll still go with my version though. It's about 1/3 of 
the code in getopt.c.

>> I've written a function which takes identical input and is fully 
>> compatible in simple parsing but handles non-option arguments 
>> identically on all systems (by populating a linked list of strings). 
>> It also has support for obscuring sensitive arguments, such as 
>> usernames and passwords.
> 
> 
> Interesting idea, especially obscuring sensitive arguments. Patch? I'm 
> sure GNU coreutils may be interested.
>

I doubt it. For them it's more about API compatibility. I worry more 
about code quality and "the user never knows". Also, my approach uses 
malloc() which is forbidden (for some reason) for getopt().

>> Lately I've become fed up with the official plugin distribution. The 
>> number of distributed bugs in allegedly stable releases is just too 
>> much work to sort out, so I've started hacking up my own framework 
>> into which I'll import the current plugins whith changes as necessary.
> 
> 
> I don't think this is a very productive comment. You work in a company 
> that sells Nagios so you can spend all your company time on our 
> software. The rest of us do it while we get on with life.
> 

You misunderstood. I'm not saying I'll deny the official distribution 
any work I do. I'm just saying that I won't put in the extra effort to 
submit patches upstream.

Besides the initial four days of patching the last time we released a 
plugin package I'll have to work extra in the future for each of those 
patches that doesn't get accepted. That extra work is lost over and over 
for each patch we need to have that doesn't get in. In the end it turns 
out to a big, fat, frustrating waste of time.

I'll put up our distro for download as soon as most of the work is done. 
It'll be GPL ofcourse so you can borrow whatever snippets you like. It's 
the method of contribution I'm fed up with. Not contributing as such.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer