On Mon, 10 Jan 2005 15:02:32 +0000 Dave wrote:
DS> > I would probably take the existing ${context}_cache_load() and include it
DS> > as${context}_container_load(), since that's really what it is doing.
DS>
DS> Ummm.... I'm not quite sure what you mean here.
DS> Under what circumstances would 'container_load' be called for a
DS> non-caching module? When the agent first starts up, during normal
DS> operation, or when?
Yes, at startup. Then it would be up to the module to maintain it during
runtime.
DS> As I'd envisaged it, the container would be initialised as part of
DS> the module startup (in ${context}_container_init), and from there
DS> on would only be updated in response to SET commands.
DS> That's certainly the model I've been working with for my example
DS> table (though I haven't got on to row creation/deletion yet).
That's fine. But what I don't want to lose is the example code in
container_load, which shows how to allocate the rowreq, set indexes and insert
the rows.
Remember, the idea here, by default, is to have small functions that perform
simple tasks. Initializing the container is different that loading it with the
initial data. Besides, the separation will make the cache code easier. Reuse.
--
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
