On Wed, 2005-01-12 at 22:19, Wes Hardaker wrote: > 1) Robert's goal with the baby steps (as part of what was needed for > the MFD stuff) was to make it possible to write small constrained > pieces of code. From the admittedly little bit I've played with > it, I think he's accomplished that.
I agree. There are probably some minor tweaks I'd want to suggest (both to baby_steps and MfD), but the basic framework is a useful one. > 2) I do think that we need a better architecture for dealing with SET > processing than exists now. It is hard to deal with cross-module > problems. In part because there is not enough definition about > when to do what where. But is that due to a lack of information, or a failure of the basic design? If it's simply down to documentation, then That Bloody Book might be of some use. If it's a more fundamental problem, then I might as well give up now (and watch you try to re-open the AgentX working group!) > 3) There are two options forward: > > A) leave the existing 6 state diagram in place as is and map the > baby steps to it. That would certainly be my preference. > B) put the baby steps (or other agreed upon architecture) in place > and map the older steps to spots in the newer one. > > There are disadvantages and advantages of both (sigh): Aren't there always :-) > A [leave existing]: > Dis: doesn't allow modules all implementing the various > micro-defined steps to interact with each other and bail out > earlier together. Fair comment. Though R/A/C-style modules (including AgentX subagents) will inevitably put something of a restriction on this as well. > B [new but mapped back]: > Dis: Unfortunately, mapping the old states back on to the newer > diagram means that the older state code will invariable be doing > things "at the wrong time". <Nods> That's why this feels more of a hack to me than A does. And there's probably a bit more of an overhead involved (ten traversals of the handler chain rather than four for a successful request), though it's not clear how significant that would be in practise. (It would also depend on the balance between R/A/C and baby_steps- based modules, and hence the use of conversion helpers). > Thus, unless all the code changed including updating the AgentX protocol! > [forget it] to accommodate the new state mechanism, the error > conditions it would have to handle for stuff happening out of > place still need to be dealt with. Yup. > My gut feeling (which is actually thought out over the year+ that > Robert has been working on this stuff) is that B is a better way to go > still. So that's another vote "in favour" ? Or just "sympathetic"? > So, I think B is the right choice. So noted :-( > Robert> I think a mechanism to have the agent use a new state map will > Robert> go in, but as a result of this discussion it could be any one > Robert> of: > > Robert> a) a full replacement, w/a helper for existing modules > Robert> b) an addition, with an ifdef to switch between the two. default tbd > Robert> c) an addition, with the internals made generic so that it can > Robert> be determined at runtime, or perhaps both be used simultaneously. > > Robert> I like c, but I don't know how easy it would be to pull off... No - I don't think that's a good idea. If you're going to make this change, then make it. Don't faff about with half-measures (b or c). That will just complicate the code even more. If you think it's worth doing, then have the courage of your convictions and go for it. 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
