Dave> But now the handler seems to return success or failure immediately,
Dave> without actually calling any lower-level handlers.
Dave> This seems to be at odds with my understanding of the handler design.
Robert> A while ago I added a 'flags' field to the mib handler structure.
Robert> One of the flags avaiable is 'AUTO_NEXT', which if set, will call
Robert> the next handler automatically. Seemed this behaviour belonged at
Robert> a higher level. I've updated several handlers to use it, eliminating
Robert> the redundant loop.
Errr... what loop?
Calling the next handler in the chain is a single statement:
return netsnmp_call_next_handler(handler, reginfo, reqinfo,
requests);
That seems just as straightforward as setting
ret->flags |= MIB_HANDLER_AUTO_NEXT;
and has the advantage that it occurs within the helper handler routine
itself. I personally find this much clearer than having to look back
at the initialisation code to see what flags may or may not have been set,
and then working out what effect they will have.
Maybe I just missed the discussion of this design change, but
I'm not at all convinced that this is an improvement or necessary.
Robert> The next level ... would also be to add flags for the various modes,
Robert> so that a handler could indicate it never wanted to be called for
Robert> certain modes.
That seems more reasonable.
Although you would get exactly the same effect using:
int some_handler( .... )
{
switch (reqinfo->mode) {
case MODE_THIS:
case MODE_THAT: return SNMP_ERR_NOERROR;
:
}
}
(which would again be coded "in-line", and hence clearer IMO)
But I'd still want to raise a note of caution.
One of the strengths of the original handler chain model was the way
that it allowed later handlers to override the effect of earlier ones
(e.g. "fixing" apparent error cases). If the chain isn't invoked at
all for a given mode, then this is no longer possible.
That's not necessarily a problem, of course - if something is declared
as read-only, then it's perfectly reasonable to block all SET requests.
But it's something that should be used with restraint.
But this feels somewhat less confusing than the AUTO_NEXT behaviour,
which I really don't think is necessary. But I'm probably in a
minority of one yet again.
Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
