On Fri, 07 Jan 2005 10:34:45 +0000 Dave wrote:
DS> It appears that in most cases, the MfD framework effectively splits
DS> each pass of the "traditional" SET handling model
Yes. The idea is that eventually the agent will use the baby step modes, and a
helper will be created to map back for the old style modes. That was supposed
to make it in to 5.2, but didn't. Probably won't make it into 5.3 either.
DS> two - one working with the table as a whole, and one working with
DS> individual columns.
DS> Thus:
DS> R1 pre_request (T) + check_objects (C)
DS> R2 undo_setup (T) + undo_setup_column (C)
DS> A commit (T) + set_values (C) (switched)
DS> U undo_commit (T) + undo_values (C)
DS> C undo_cleanup/post_request (T)
DS>
DS> That's an oversimplification, of course, as it's ignoring
DS> the object_lookup (in R1) and check_consistency (in A) calls.
DS> But is it a reasonable summary?
First, just a clarification for out listeners. The above summary doesn't
represent the order that things actually happen, and is a specific
interpretation of what MFD does with baby step modes. Nothing in the baby-steps
is particular to tables. It would work just as well for scalars. If you
substitute'handler' for 'table', and 'object' for 'column', what you've got
looks reasonable.
Also note that the MFD code uses the row_merge helper, so that factors in as
well.
DS> The obvious oddity is the Commit handling - there's nothing
DS> that works on committing individual columns.
Correct. This is only because the tables I've dealt with all keep column data
in the same place, so I haven't needed commits for individual columns. It would
be quite easy to add column commits and a variable to control their generation.
(A similar variable could control whether or not individual get, set,
validation and undo routines are generated. It would effectively move a good
bit of code out of the interface file and into the get/set files. ie one big
function instead of lots of little ones.)
DS> But checking the MfD framework code against the baby_steps flowchart,
DS> the "irreversible commit" mini-mode isn't being used at all.
DS> Is this deliberate?
It can be used, it just isn't generated by default. The idea is to strongly
encourage the use of undo-able commits.
DS> Or might it make sense to use this to support per-column commit hooks?
No, if you want per-column commit hooks, that can be done in the set mode in
exactly the same fashion as the current get/set/etc column modes are handled.
DS> In fact, the 'undo_cleanup' and 'post_request' hooks are
DS> shared by COMMIT, FREE and UNDO so there's nowhere in the
DS> MfD framework for handling table-wide COMMIT-only processing.
Well, you can't please all the people all the time. ;-)
DS> So perhaps the 'irreversible_commit' hook should trigger both
DS> table- and column- level routines
No, regular commits should remain within the confines of the commit mode. The
same type of shenanigans needed for a table level commit with all the other
helpers are also currently needed for mfd. It wouldn't be too hard, however, to
hide the shenanigans in the interface code, so the user just sees a
${context}_commit_table() or some such function.
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. The only mini-modes called during this pass
DS> are 'undo_cleanup' and 'post_request', both of which are also
DS> called in the UNDO and COMMIT passes.
Yes, I've had this argument with Wes as well. undo-cleanup is really the
equivalent of the free-only mode.
DS> Might it not be worth introducing another mini-mode into
DS> the baby_steps helper, called only in the FREE pass and *before*
DS> these two (i.e. following a failure in the check_values or
DS> undo_setup mini-modes)?
I don't think so.
First off, check_values should not be allocating resources (note in the flow
chart, and error in check values does not call undo cleanup - it goes straight
to post-request).
Second, commit and set both have their own undo functions. Any cleanup specific
to those modes can happen there. In some cases, that may be as simple as
twiddling some bits for undo_cleanup.
DS> In fact, it might even be useful to support different hooks
DS> for these two paths
It might be useful, but I'd much rather not add more states. I really think the
goal should be the simplest state diagram possible.
Of course, the beauty of the chained handler system is that you can insert a
helper to expand or collapse modes at will. ;-)
DS> One final (very minor) point - there are a number of
DS> irritating inconsistencies between the baby_steps diagram,
DS> the names of the mini-modes, the names of the various hooks,
DS> and the template code generated by the MfD framework:
WHAT? Inconsistencies in our documentation! Say it isn't so! :-P
DS> It's probably not possible to bring all of these into line, but
DS> my gut feeling is that the documentation (the flow diagram)
DS> should perhaps be tweaked to match the public interface (the
DS> hook names). And it ought to be safe to adjust the MfD template
DS> framework as well.
I have no objections.
--
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
