On Thu, 13 Jan 2005 10:52:21 +0000 Dave wrote: DS> > DS> It's simpler to understand the detail of each individual step, DS> > DS> but it's much harder to understand how it all fits together. DS> > DS> DS> > DS> I think the existing model is much easier to understand, but needs DS> > DS> more thought as to the close-in detail. DS> > DS> > Isn't "more thought as to the close-in detail" the same thing as "[hard] DS> > to understand how it all fits together"? DS> DS> No. DS> DS> It's easy to grasp the overall picture with the current framework: DS> DS> - check the request and get everything ready DS> - actually make the assignment DS> - tidy up afterwards
That's only 3 step, for 6 states. As a matter of fact, I could use the exact same summary. DS> with suitable error handling after the first two. DS> That's "understanding how it all fits together". Note that you've completely glossed over error handling. This is exactly why I split out error handling for each phase. DS> It is *not* easy to grasp the overall picture with the baby_steps DS> model - witness the need for the flowchart. Ahem. http://www.net-snmp.org/tutorial/tutorial-5/toolkit/mib_module/set-actions.jpg DS> Having to come to terms with a ten-stage pipeline for a successful request DS> is a much steeper learning curve, IMO. Of course I disagree. I would much rather have the steps I need to deal with be explicit from the beginning, rather than having to figure it out as I go along or after the fact. DS> I view this flow chart as an extremely useful refinement of the DS> general structure, filling out more detail of exactly what is DS> involved at each stage - "the close-in detail". DS> But it's not particularly clear as a basic model. DS> > DS> So the current framework of "baby_steps on top of R/A/C" is a DS> > DS> reasonable one. Switching to "R/A/C on top of baby_steps" would DS> > DS> mean adopting the worst bits of both approaches. DS> > DS> > The problem is that "baby_steps on top of R/A/C" is a hack because it is DS> > expanding the state diagram. DS> DS> I don't see that as a hack - I see that as a refinement. The hack part is that two modules using the new method aren't coordinated in their execution of states. Both modules will execute all the sub-steps for the old state in the error case. DS> > However, "R/A/C on top of baby_steps" could be DS> > done much cleaner, because it would just ignore states it didn't need. DS> DS> Whereas I see *that* as a hack, since it means doing some tasks DS> in the "wrong" step. If you were to try and provide a simple 1-1 mapping from a single new state to an old state, that *might* be true (I haven't examined that tack). But that isn't the plan. And intelligent helper will ensure correct behaviour. DS> > On Mon, 10 Jan 2005 15:02:38 +0000 Dave wrote: DS> > DS> But what if the only way to check particular values does involve DS> > DS> allocating resources? Perhaps ..... to lock some shared subsystem? DS> > DS> ..... Without some form of'free_only' step, such resources DS> > DS> would need to be retained until the 'post_request' step. DS> > DS> > And the problem with that is...?? DS> DS> That the lock might well need to be released in order to actually DS> set the new values. Then why wouldn't it have been released immediately after the check? DS> > Note that in the error case, post_request is the next state. DS> DS> Yes - and in the non-error case, it'll be undo_setup (release the DS> lock) then do a whole lot of other things, then call post_request DS> (release the lock again???) Ok, having looked at the old state diagram, it has exactly the same problem. Actually, I think it is worse, which is why baby_steps is the way it is. Let's take the more common scenario of a database that has to be locked from start to finish. The lock is obtained in reserve1 or reserve2. There are 3 possible exit points for a set, so the database must be closed in free, undo and commit. This is exactly why baby steps has a single exit point DS> > (Besides which, if you were going to close the db in the very DS> > next state, why not just close it at the end of the check state?) DS> DS> And if there are two cooperating objects (implemented using DS> separate handler chains)? The first one can grab the lock, DS> but this shouldn't be released until after the second one has DS> finished making it's checks. DS> So the first opportunity for the first object has to release DS> the lock would be in undo_setup. Do you mean undo_cleanup? Because undo_setup is the very next state after checks, so the delay should be no different than between any 2 states in the old state map. Again, this exact same issue exists with the old states. Besides which, since there is no guarantee as to which handler will be called first, both handlers need to have some cooperating method of locking the database and letting the other handler know it has done so. Thus the second handler could simply close the database when it's checks were done. I fail to see how a new state helps this problem. In any cooperating scenario the modules need some external communication method. DS> No - I'm talking about an *action* that needs to happen: DS> DS> a) after a successful check_values step, but before the commit DS> and DS> b) after an unsuccessful check_values step DS> DS> These are mutually exclusive - only one will apply to any given request. DS> But the same action would need to appear in two steps - 'undo_setup' DS> and the (missing) 'free_only' step. A whole new state is just plain overkill for this. check_values: db = get_db() ... undo_setup: close(db) db = NULL post_request: if(db) close(db) Adding reference counting to handle multiple rows or cooperating tables is a simple exercise left to the reader. DS> > I still maintain that it can be handled quite easily without an DS> > additional state. DS> DS> And I still think you're wrong. What is so hard about the simple pseudo-code outlined above? DS> Two new states: DS> one invoked between 'check_values' and '(err && f1)', and DS> one invoked between 'undo_setup' and 'undo_cleanup' DS> DS> i.e. in those two long "error lines' down the left hand side of DS> the flowchart. I see absolutely no value in inserting new states that aren't decision points. Any state that had a single input and a single output can be implemented in the previous or next state. -- 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
