DS> But is there any way of generating such a [irreversible_commit] hook?
RS> Yes - it's a bit complicated at the moment. Probably should be made easier. RS> You have to generate the code, then edit default-table-X.m2d and RS> change the m2c_irreversible_commit flag to 1, Aha! That's the flag I was looking for. Just to check - this should also work if you start by creating a file default-table-X.m2d containing "@set $m2c_irreversible_commit=1@' and the generate the code (for the first time) - yes? That's certainly how I've been documenting things in the book with some of the other flags. RS> keep in mind that you're about 2 releases late for the design discussion. RS> So I'm not sure how much we can change w/out breaking backwards compatability. Well, adding new steps shouldn't break existing code, since the relevant hooks won't be set. Those particular steps would simply be skipped. DS> The other thing that strikes me about the baby_steps flow DS> of control, is that there isn't anywhere for "FREE-only" DS> processing. RS> undo-cleanup is really the equivalent of the free-only mode.... RS> ... it is not a full equivalent. I don't intend to have one to one mappings RS> to the old modes. Those needing the exact equivalents can use the old API. That's fine at the moment, when I've got the option of whether to use the baby_steps framework or not. But if you do end up using this as the fundamental model for the agent, then that's going to cause problems for the old API style. RS> The real questions are, IMHO, can it handle all the cases the old RS> API can, and is it simpler to understand. I think the answer to RS> both questions is yes. And I think the answers are "mostly" and "no". It's simpler to understand the detail of each individual step, but it's much harder to understand how it all fits together. I think the existing model is much easier to unddrstand, but needs more thought as to the close-in detail. It also fits very neatly into the standard AgentX protocol behaviour. So the current framework of "baby_steps on top of R/A/C" is a reasonable one. Switching to "R/A/C on top of baby_steps" would mean adopting the worst bits of both approaches. DS> Because it's not "free-only" - it's "free-and-undo-and-commit". RS> No no no - there are separate states for commit and undo Yes - but there *isn't* a separate state for free. The only possible candidate is shared by free, undo and commit. Now you may not think that matters, but I don't see how you can deny it. RS> Maybe if you gave me a more concrete example of a case that you RS> think it can't handle? That's what I was trying to do in the next bit. 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. RS> Right, and I think that's an acceptable solution. But you snipped the other example - of locking some resource that needs to be released as soon as possible. Having to leave that locked throughout the full processing of the SET request is *not* an acceptable solution IMO. RS> I still don't see what another mode buys you that can't be done RS> with the existing modes. Anything that needs to be done somewhere after the 'check_values' (or 'undo_setup') step regardless of success or failure, but must be done before the commit step. I think it's a mistake to say that "we can't think of anything, so no-one will ever need this" - we've got bitten by that before. Particularly when this could be handled quite easily. You've more than doubled the number of processing steps already. Why are you so implacably opposed to adding a couple more? 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
