On Wed, 12 Jan 2005 10:02:53 +0000 Dave wrote: DS> Just to check - this should also work if you start by creating a file DS> default-table-X.m2d containing "@set $m2c_irreversible_commit=1@' DS> and the generate the code (for the first time) - yes?
Errr... yes. However, the disadvantage would be that if the default-table-X.m2d file exists, it is read in but not re-written. So it wouldn't be populated with the other defaults available to the user. It really should be added to the interactive setup file. DS> RS> undo-cleanup is really the equivalent of the free-only mode.... DS> RS> ... it is not a full equivalent. DS> DS> That's fine at the moment, when I've got the option of whether to use DS> the baby_steps framework or not. But if you do end up using this as the DS> fundamental model for the agent, then that's going to cause problems DS> for the old API style. Do you really think I'd try and change the agent internals such that most of the existing modules would break?? I know you have a low opinion of me, but I didn't think it was that low!! DS> It's simpler to understand the detail of each individual step, DS> but it's much harder to understand how it all fits together. DS> DS> I think the existing model is much easier to unddrstand, but needs DS> more thought as to the close-in detail. Isn't "more thought as to the close-in detail" the same thing as "[hard] to understand how it all fits together"? Anyhoo, as usual, we'll just have to agree to disagree. DS> So the current framework of "baby_steps on top of R/A/C" is a DS> reasonable one. Switching to "R/A/C on top of baby_steps" would DS> mean adopting the worst bits of both approaches. The problem is that "baby_steps on top of R/A/C" is a hack because it is expanding the state diagram. However, "R/A/C on top of baby_steps" could be done much cleaner, because it would just ignore states it didn't need. DS> DS> Because it's not "free-only" - it's "free-and-undo-and-commit". DS> RS> No no no - there are separate states for commit and undo DS> DS> Yes - but there *isn't* a separate state for free. DS> The only possible candidate is shared by free, undo and commit. DS> Now you may not think that matters, but I don't see how you can deny it. I'm not denying that there isn't a state that directly corresponds to the old free state. I'm saying there is no need for an additional state in the baby_steps to accomplish what you want to do. DS> But you snipped the other example - of locking some resource that DS> needs to be released as soon as possible. Having to leave that DS> locked throughout the full processing of the SET request is *not* DS> an acceptable solution IMO. On Mon, 10 Jan 2005 15:02:38 +0000 Dave wrote: DS> But what if the only way to check particular values does involve DS> allocating resources? Perhaps to do some database lookup, or to DS> lock some shared subsystem? And suppose that these would naturally DS> be released in the 'undo_setup' step? Without some form of DS> 'free_only' step, such resources would need to be retained until DS> the 'post_request' step. And the problem with that is...?? Note that in the error case, post_request is the next state. (Besides which, if you were going to close the db in the very next state, why not just close it at the end of the check state?) DS> RS> I still don't see what another mode buys you that can't be done DS> RS> with the existing modes. DS> DS> Anything that needs to be done somewhere after the 'check_values' DS> (or 'undo_setup') step regardless of success or failure, but must DS> be done before the commit step. Ok, now I'm *really* confused. I thought you were talking about a free only state, but now you are talking about a state that happens before commit? that definitely wouldn't be any sort of free only state, and there is no corresponding state in the old api. DS> I think it's a mistake to say that "we can't think of anything, DS> so no-one will ever need this" - we've got bitten by that before. And I think the new handler parameters and data structures are sufficient for additional flexibility. DS> Particularly when this could be handled quite easily. I still maintain that it can be handled quite easily without an additional state. DS> You've more than doubled the number of processing steps already. DS> Why are you so implacably opposed to adding a couple more? Because I think it's sufficient as is, and I still don't see the benefit for the additional steps. Let's try another tack. What, exactly are the states you want to add, and where would the fit into the flow chart? -- 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
