On Tue, 2005-01-11 at 06:34, Wes Hardaker wrote: Wes> Depends on where you [inject the handler]. Dave> During the course of processing a request. Wes> Err... um, *why* would you ever do it during request processing?
Because it's the only place where the agent knows about the rest of the handler chain (and hence whether it can handle GETSTASH requests or not). The 'netsnmp_get_stash_cache_handler()' routine doesn't have access to information about the rest of the chain. The netsnmp_register_xxx() API does, but that's typically called *before* the stash_cache is injected. And I really don't want to put special-case code into 'netsnmp_inject_handler' ! Wes> Why not parallel the way the bulk_to_next handler does it? Because that's relevant for *every* handler chain - it's not tightly linked to a particular helper. If a handler chain doesn't contain the stash_cache helper, then the stash_to_next helper is completely irrelevant. I don't want to clutter up every single handler chain with something that won't be needed 99% of the time. Dave> a) Live dangerously, and inject the stash_to_next handler Dave> into the chain while it's processing the (first) request, Dave> [ The current mode of operation ] Wes> not in my favor, as mentioned. Also sacrifices efficiency Wes> during processing of the important stuff. It's probably slightly more efficient than calling the stash_to_next handler in a chain that *does* already support GETSTASH - a single test is less overhead than a function call, two tests and return. (We could remove the stash_to_next helper from the chain if it supported GETSTASH, but that just another example of dynamically updating the handler chain - and a somewhat more problematic one!) But I take your point regarding safety. Dave> b) Have 'netsnmp_get_stash_cache_handler()' return a Dave> mini-chain of *both* the stash_cache and stash_to_next Dave> handlers, and inject these two into the handler chain Wes> that'd be acceptable in my eyes. OK - I'll have a look at that approach. Dave> [ assuming 'netsnmp_inject_handler' supports Dave> working with more than one handler, of course ] Wes> But that'd need to be fixed, as I don't think it does. I had a feeling that might be the case (though I hadn't actually checked). Shouldn't be too much of a problem to fix, though. Wes> e) agent_handler.c near line 240 See comments above. Dave ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
