On Fri, 07 Jan 2005 13:31:15 +0000 Dave wrote:
DS> I noticed a log message on the CVS list yesterday,
DS> about documenting how to implement a non-caching version
DS> of a container-based MfD module.
DS> (I was a bit surprised to see that you'd applied this
DS> to the 5-2-patches line as well, since I thought that was
DS> currently in pre-release freeze, but that's by-the-by).
I thought comment changes were always fair game. And comments in mib2c conf
files seems even safer. No?
DS> I presume that the effect of clearing the 'cache->enabled'
DS> flag is simply to bypass all of the cache-related code.
DS> It will still be there, but will never actually be called.
DS> Is that correct?
right. It was the quickest solution.
DS> I'm appending a new "mfd-access" file, that could be used
DS> to generate code which omits all of the cache-related
DS> processing altogether - generating a purely internal data
DS> MfD-based MIB module, with consequentially simpler code.
Yeah, that has been on my TODO list as well.
What I probably would have done would have been to define a new variable to
make the cache stuff conditional. What probably makes more sense, however,
would be an access-container (pretty much what you've done) that has a variable
to include the cache stuff from a pared down access-container-cached.
I would probably take the existing ${context}_cache_load() and include it as
${context}_container_load(), since that's really what it is doing. Similarly,
${context}_cache_free, _cache_item_free() and _cache_free() should really be
container functions. So the container-cached file will mostly be stub functions
calling these functions more frequently then a non-cached function would.
It would probably also make sense to add a new m2c_processing_type for setup,
so the interactive setup stuff could go into the defines file, instead of
having the top level interactive setup have to know about every option.
But what you've got is a good starting point. I'd say take out the 'updating
the Index' section (since the function isn't defined in the file, it shouldn't
be documenting it), pull in and rename the functions I mentioned above, and go
ahead and check it in. I can work out the details of merging the two to
eliminate redundant code later.
Oh, and thanks for asking ahead of time.
--
Robert Story; NET-SNMP Junkie
Support: <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.
-------------------------------------------------------
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
