Robert,
thanks for having a look at the caching problems.
But I'm a little concerned/confused about the cache handler
as it currently stands.
Firstly, there appears to be an inconsistency in the
way that the cache is referenced
At the beginning of the handler (and again in the COMMIT
pass), it uses the local 'myvoid' pointer set up when the
handler was first created (using netsnmp_get_cache_handler).
So this is what I tweaked the first-pass (and subsequent SET
handling) code to use.
The most recent change now uses what appears to be a
completely separate cache structure, extracted from an
internal list. If these *are* different cache structures,
then this seems extremely dangerous (if not plain wrong!).
If they actually refer to the same cache structure, then
I don't see the point in searching for something that's
already available directly.
The second issue relates to the overall form of the handler routine.
The general model of the v5 handler chain architecture is of a series
of routines, each of which takes care of certain aspects of the request
and then passes control on to the next handler. I'm pretty sure that
when I first wrote the original cache handler, it took this basic form.
But now the handler seems to return success or failure immediately,
without actually calling any lower-level handlers. At first sight,
I don't see how this can work at all (though clearly it does).
This seems to be at odds with my understanding of the handler design.
Could you shed a little light on the thinking behind this particular
arrangement?
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
