DS> I think the pipeline has some advantages - it's somewhat more flexible
DS> in terms of exactly when and where the next handler is called,
DS> and what (if anything) is done afterwards.
Robert> I don't think what I'm proposing takes away any flexibility.
Ok - maybe an example would help.
Suppose I'm writing a helper (say to time how long a request takes),
that needs to do something both before and after calling the lower handlers.
With the current pipeline model, that would be:
int stopwatch_helper_handler( .... )
{
begin = time(NULL);
ret = netsnmp_call_next_handler( ... );
end = time(NULL);
log( end-begin );
return ret;
}
How would that be done using the sequential model?
In particular, how does that model cope with "post-processing" requirements?
That's the particular flexibility that doesn't seem to be handled as it stands.
(Unless I've missed something - not for the first time)
Robert> I think both are necessary. The 99% case will be lower handlers that
Robert> know nothing about handlers below them, and don't care. The next
handler
Robert> will be called for them.
Robert> Some of the helper handlers, however, do care. Again, bulk_to_next is
Robert> the best example. It needs to do something before and after lower
Robert> handlers are called.
Which is exactly what I was referring to above!
I've just had a look at all of the currently existing helpers, and this
situation is actually more common than I expected. Of the 23 C files
in the 'helper' folder:
1 doesn't contain a helper at all (all_helpers)
1 doesn't call any lower helpers (null)
1 has already been converted (cache_handler)
5 don't do anything after calling 'netsnmp_call_next_handler'
so could be converted trivially
(multiplexer, read_only, table_array,
table_dataset and watcher)
The other 15 all do *something* following the 'netsnmp_call_next_handler'
call. Now in many cases, this is fairly trivial:
4 need to convert GETNEXT->GET and back again
3 need to repack separate results back into a single sequence
2 need to retry "sparse" results
2 need to adjust from an instance OID back to a scalar
1 needs to call some callback routines (mode_end_call)
1 just needs to display some output (debug)
However, I suspect that most of those could be handled with suitable
"post-process" routines. That would just leave two handlers that wouldn't
obviously fit into this particular model: baby_steps and stash_cache
DS> If we're going to work this way, then I think we need to first
DS> agree on this (and exactly what model to use), and then make a
DS> concerted effort to make the change across the board.
Robert> Well, we need to come to consensus real quick then. 5.2 is rapidly
approaching.
I'm sorry that I didn't become aware of this implicit design change earlier.
I do tend to rely on the mailing lists for a feel of what's happening and/or
planned for this project. IRC etc. is much less convenient for me.
But I'll do my best not to delay things too much.
OK - how about the following model:
- By default, handlers return success/failure, but don't explicitly
call the next handler in the chain. This is (normally)
done by the main netsnmp_call_next_handler routine.
(i.e. AUTO_NEXT becomes the default)
- Handlers that need to do post-processing should set a suitable flag
(i.e. the inverse of AUTO_NEXT) and are then responsible
for calling netsnmp_call_next_handler at the appropriate
point (giving the next handler in the list).
The "upper" netsnmp_call_next_handler would check the
flag when the main handler returned, and decide whether
to continue with the chain.
- We code three or four trivial NONE_AUTO_NEXT handlers to cope with
the most common post-processing requirements (GET->GETNEXT,
retry sparse results, ?instance->scalar, ??repack results)
and tweak the relevant helper modules to use them.
That would mostly flatten the handler chain stack - it would only increase
in depth when these NONE_AUTO_NEXT helpers were called. And not necessarily
even then - the GET->GETNEXT handler could be as simple as:
int ret = SNMP_ERR_NOERROR;
if ( reqinfo->mode == MODE_GETNEXT ) {
handler->flags |= NONE_AUTO_NEXT;
ret = netsnmp_call_next_handler( ... );
reqinfo->mode = MODE_GETNEXT;
}
return ret;
We could then get a mostly-consistent set of helpers, where only the
"unusual" cases needed to do anything special.
An alternative approach might be to have *two* handler routines for each
helper module - the main one, which would be called in sequence for each
handler in the chain, and a "post-process" one, which would be called in
*reverse* sequence, working back up the chain again.
In some ways, that's perhaps a slightly simpler model, though it would
mean splitting existing handlers in two. And is probably less flexible
overall. But it's a possibility.
How does that sound?
DS> Now I've just got to work out what this means w.r.t. the descriptions
DS> for the book. I'm more and more thinking that I should have followed
DS> my initial impulse, and pulled out of the project completely until
DS> that was finished.....
Robert> Hmm.. pulled out of what project until what was finished?
Net-SNMP
Robert> At any rate, it's just like my inetNetToMedia problem.
Robert> It's never easy to track a moving target.
That's partly it, certainly.
But I'm also suffering from trying to do too much at once.
Time spent tackling bugs (for example) or arguing with you,
is time I'm not spending on the book (or doing what I'm
actually being paid for!)
But I'm congenitally incapable of seeing something going on,
and not chipping in when I think things are moving in the
wrong direction, or need some other input.
The only way I could have managed to concentrate on the
one task would be to have unsubscribed from the mailing lists,
stopped looking at the code, and let the Net-SNMP project carry
on without me. And it's probably a bit late for that now.
(Probably!)
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
