On Mon, 10 Jan 2005 15:02:41 +0000 Dave wrote: DS> On Fri, 2005-01-07 at 16:29, Robert Story wrote: DS> > On Fri, 07 Jan 2005 10:34:45 +0000 Dave wrote: DS> > DS> It appears that in most cases, the MfD framework effectively splits DS> > DS> each pass of the "traditional" SET handling model DS> > DS> > Yes. The idea is that eventually the agent will use the baby step modes, DS> > and a helper will be created to map back for the old style modes. That DS> > was supposed to make it in to 5.2, but didn't. Probably won't make it DS> > into 5.3 either. DS> DS> Hmmm.... I'm not sure I remember that decision. Or even the discussion DS> that presumably preceded it. And (as you might have guessed!), I don't DS> think it's a good idea.
Well, I know I've mentioned it before: On Thu, 12 Feb 2004 11:09:28 -0500 Robert wrote: RS> On Thu, 12 Feb 2004 14:24:28 +0000 Dave wrote: RS> DS> (Particularly with the MFD helper, where the whole processing RS> DS> model seems completely different!) RS> RS> The intent, I believe, to to revamp the internal handling to match the RS> 'baby steps' model, with a helper to provide and 'old mode' mapping. We RS> just haven't gotten to that part yet. and then again 7 months later, where you did sit up and take notice (and object, of course). DS> It would mean that the six existing passes would have to be shoe-horned DS> into selected steps of the baby_steps framework, shoe-horned? Doesn't that usually imply putting something bigger into something smaller? This is the other way round, it should be much easier. DS> That introduces unnecessary confusion, IMO. But it would be completely transparent to the users. And I'll be glad to help out anyone looking at the internal code. DS> Not to mention that the current baby_steps framework cannot properly DS> handle invoking the FREE pass - at least not without contortions to DS> avoid getting this mixed up with the UNDO and COMMIT passes as well. So there are contortions - that's quite common in our code base. But it will be transparent to the users. DS> What are the benefits of changing the architecture of the agent? Aha, now we get to the heart of the matter. The great thing about new APIs is that we aren't bound by the restrictions of the old APIs. The primary benefit will be the granularity of error handling during set processing. An error occurred during the set mode of the second vb? Skip the rest, and only call undo for handler for the first two. Of course, this benefit will only be seen by handlers using the new modes. Old handlers will continue to see the existing behaviour. -- 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
