On Thu, 01 Jul 2004 12:41:19 +0100 Dave wrote:
DS> Robert> I don't think what I'm proposing takes away any flexibility.
DS>
DS> Ok - maybe an example would help. [...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best example. It needs to do something before and after [...]
DS>
DS> Which is exactly what I was referring to above!
And is currently possible... it's already done in table.c:
/*
* send GET instead of GETNEXT to sub-handlers
*/
if ((oldmode == MODE_GETNEXT) && (handler->next)) {
/*
* tell agent handlder not to auto call next handler
*/
handler->flags |= MIB_HANDLER_AUTO_NEXT_OVERRIDE_ONCE;
if(need_processing > 0) {
agtreq_info->mode = MODE_GET;
rc = netsnmp_call_next_handler(handler, reginfo, agtreq_info,
requests);
...
DS> I've just had a look at all of the currently existing helpers, and this
DS> situation is actually more common than I expected.
Oh, I expect it to be fairly common there. That's fine, because that's our code
and we should be expected to know the tricks of the trade. However, actual
table handlers should far outnumber helpers.
DS> The other 15 all do *something* following the 'netsnmp_call_next_handler'
DS> call. [...]
DS>
DS> However, I suspect that most of those could be handled with suitable
DS> "post-process" routines.
I agree... I actually proposed a pre_post helper in my response to Wes, before
I read your message.
DS> That would just leave two handlers that wouldn't
DS> obviously fit into this particular model: baby_steps and stash_cache
And 2/24 non-standard isn't so bad.
DS> Robert> Well, we need to come to consensus real quick then. 5.2 is rapidly
DS> approaching.
DS>
DS> I'm sorry that I didn't become aware of this implicit design change
DS> earlier. I do tend to rely on the mailing lists for a feel of what's
DS> happening and/or planned for this project. IRC etc. is much less
DS> convenient for me.
Actually, being IRC wouldn't have helped you any. In main line cvs, I don't
think too much about a code change that is transparent to the end user and
backwards compatabile.
DS> - By default, handlers return success/failure, but don't explicitly
DS> call the next handler in the chain. This is (normally)
DS> done by the main netsnmp_call_next_handler routine.
DS> (i.e. AUTO_NEXT becomes the default)
Well, the problem there is that it's not backwards compatible. A
user-implementation that is calling call_next would suddenly be getting two
callbacks.
Be I think making if the default for the version 6 api would be a good idea.
;-)
DS> - Handlers that need to do post-processing should set a suitable flag
DS> (i.e. the inverse of AUTO_NEXT) and are then responsible
DS> for calling netsnmp_call_next_handler at the appropriate
DS> point (giving the next handler in the list).
DS> The "upper" netsnmp_call_next_handler would check the
DS> flag when the main handler returned, and decide whether
DS> to continue with the chain.
DS>
DS> - We code three or four trivial NONE_AUTO_NEXT handlers to cope with
DS> the most common post-processing requirements
I think this could be done with a suitable pre_post helper.
DS> That would mostly flatten the handler chain stack - it would only increase
DS> in depth when these NONE_AUTO_NEXT helpers were called.
What you've proposed is pretty much the way it works now, except the default
for the flag is no auto next.
DS> We could then get a mostly-consistent set of helpers, where only the
DS> "unusual" cases needed to do anything special.
Sound good.
DS> An alternative approach might be to have *two* handler routines for each
DS> helper module - the main one, which would be called in sequence for each
DS> handler in the chain, and a "post-process" one, which would be called in
DS> *reverse* sequence, working back up the chain again.
Again, that's a pre_post helper (with a null pre handler).
DS> DS> Now I've just got to work out what this means w.r.t. the descriptions
DS> DS> for the book. I'm more and more thinking that I should have followed
DS> DS> my initial impulse, and pulled out of the project completely until
DS> DS> that was finished.....
DS>
DS> Robert> Hmm.. pulled out of what project until what was finished?
DS>
DS> Net-SNMP
Ack!
DS> Robert> It's never easy to track a moving target.
DS>
DS> That's partly it, certainly.
DS> But I'm also suffering from trying to do too much at once.
DS> Time spent tackling bugs (for example) or arguing with you,
DS> is time I'm not spending on the book (or doing what I'm
DS> actually being paid for!)
I know the feeling. I'll try and be less argumentative. :-)
DS> The only way I could have managed to concentrate on the
DS> one task would be to have unsubscribed from the mailing lists,
DS> stopped looking at the code, and let the Net-SNMP project carry
DS> on without me. And it's probably a bit late for that now.
DS> (Probably!)
Double ack! We'd be in big trouble if you did that!
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
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
