On Mon, 10 Jan 2005 15:02:38 +0000 Dave wrote: DS> > (A similar variable could control whether or not individual get, set, DS> > validation and undo routines are generated. It would effectively move a DS> > good bit of code out of the interface file and into the get/set files. ie DS> > one big function instead of lots of little ones.) DS> DS> Hmmm.... I'm not sure I understand that last comment. DS> It would move some of the processing into the 'm2i' files, perhaps. DS> But why would it affect the get/set files - other than removing DS> irrelevant code. I certainly don't see how it would result in DS> "one big function" in these files. DS> Unless I've completely misunderstood you here?
Right now the get/set files contain individual functions for each variable (lots of little functions). These functions are called from the interface code, which has a loop and a switch to call the little functions. It wouldn't be too hard, based on a flag, to move that function into the get/set file, and generate the same code that is currently in the functions inside the switch cases. ie one big function, the way most of the other mib2c conf files generate code. DS> > DS> But checking the MfD framework code against the baby_steps flowchart, DS> > DS> the "irreversible commit" mini-mode isn't being used at all. DS> > DS> Is this deliberate? DS> > DS> > It can be used, it just isn't generated by default. The idea is to DS> > strongly encourage the use of undo-able commits. DS> DS> But is there any way of generating such a hook? Yes - it's a bit complicated at the moment. Probably should be made easier. You have to generate the code, then edit default-table-X.m2d and change the m2c_irreversible_commit flag to 1, then regenerate the code. DS> > DS> In fact, the 'undo_cleanup' and 'post_request' hooks are DS> > DS> shared by COMMIT, FREE and UNDO so there's nowhere in the DS> > DS> MfD framework for handling table-wide COMMIT-only processing. DS> > DS> > Well, you can't please all the people all the time. ;-) DS> DS> Humph. I'm not sure that's an acceptable response to a discussion DS> about possible design flaws :-) Also keep in mind that you're about 2 releases late for the design discussion. So I'm not sure how much we can change w/out breaking backwards compatability. But if you really think it's flawed, we can come up with a new methodology or fix and rename baby-steps. DS> > DS> The other thing that strikes me about the baby_steps flow DS> > DS> of control, is that there isn't anywhere for "FREE-only" DS> > DS> processing. The only mini-modes called during this pass DS> > DS> are 'undo_cleanup' and 'post_request', both of which are also DS> > DS> called in the UNDO and COMMIT passes. DS> > DS> > Yes, I've had this argument with Wes as well. undo-cleanup is really the DS> > equivalent of the free-only mode. DS> DS> Except that it's not a full equivalent. Righ, it is not a full equivalent. I don't intend to have one to one mappings to the old modes. Those needing the exact equivalents can use the old API. Try and look at it without trying to establish equivalency. The real questions are, IMHO, can it handle all the cases the old API can, and is it simpler to understand. I think the answer to both questions is yes. DS> Because it's not "free-only" - it's "free-and-undo-and-commit". No no no - there are separate states for commit and undo (actually, there are 2 undo states). DS> If you're designing a basic architecture (i.e. thinking of the DS> abstract baby_steps model, rather than the MfD use of it), DS> you really need it to be as flexible as possible. No, I think it should be as simple as possible, while allowing for flexibility. And I think I'm pretty close. DS> As it stands, there is no way to handle errors in the 'check_values' DS> or 'undo_setup' steps, without reverting to ugly workarounds such as DS> setting flags (which would need to be done in *both* 'undo_set' and DS> 'irreversible_commit', BTW) I guess I don't understand, because I really think you are asking for the impossible here. What you are describing can't be done with the old modes, either. If you allocate resources, you have to track them somehow, so you can release them. That is basic coding, not an ugly workaround. Maybe if you gave me a more concrete example of a case that you think it can't handle? DS> > First off, check_values should not be allocating resources DS> DS> But what if the only way to check particular values does involve DS> allocating resources? Perhaps to do some database lookup, [...] Without DS> some form of'free_only' step, such resources would need to be retained DS> until the 'post_request' step. Right, and I think that's an acceptable solution. I can think of several situations that aren't handled easily by default. But the situation is the same as the old api. It can be done, but is a little convoluted. Hopefully future helpers will help address those situations. I don't think it's a fundamental flaw. DS> > Second, commit and set both have their own undo functions. Any cleanup DS> > specific to those modes can happen there. DS> DS> Yes - that's fine. DS> I'm just saying that it's a flaw that there isn't something similar DS> for the FREE-style steps as well. I still don't see what another mode buys you that can't be done with the existing modes. -- 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
