Robert,
as you know, I've recently been looking at the MfD framework,
and hence the baby_steps helper that it relies on. And I've got
a couple of question - mostly just requests for clarification.
It appears that in most cases, the MfD framework effectively splits
each pass of the "traditional" SET handling model into (typically)
two - one working with the table as a whole, and one working with
individual columns.
Thus:
R1 pre_request (T) + check_objects (C)
R2 undo_setup (T) + undo_setup_column (C)
A commit (T) + set_values (C) (switched)
U undo_commit (T) + undo_values (C)
C undo_cleanup/post_request (T)
That's an oversimplification, of course, as it's ignoring
the object_lookup (in R1) and check_consistency (in A) calls.
But is it a reasonable summary?
The obvious oddity is the Commit handling - there's nothing
that works on committing individual columns. But checking
the MfD framework code against the baby_steps flowchart,
the "irreversible commit" mini-mode isn't being used at all.
Is this deliberate? Or might it make sense to use this to
support per-column commit hooks?
In fact, the 'undo_cleanup' and 'post_request' hooks are
shared by COMMIT, FREE and UNDO so there's nowhere in the
MfD framework for handling table-wide COMMIT-only processing.
So perhaps the 'irreversible_commit' hook should trigger both
table- and column- level routines (as is currently done with
the R2 'undo_setup' hook)
The other thing that strikes me about the baby_steps flow
of control, is that there isn't anywhere for "FREE-only"
processing. The only mini-modes called during this pass
are 'undo_cleanup' and 'post_request', both of which are also
called in the UNDO and COMMIT passes.
Might it not be worth introducing another mini-mode into
the baby_steps helper, called only in the FREE pass and *before*
these two (i.e. following a failure in the check_values or
undo_setup mini-modes)?
In fact, it might even be useful to support different hooks
for these two paths - something that I've mentioned before
in the context of the main SET model.
One final (very minor) point - there are a number of
irritating inconsistencies between the baby_steps diagram,
the names of the mini-modes, the names of the various hooks,
and the template code generated by the MfD framework:
"check values" (diagram) vs
"CHECK_VALUE" (BS pass) vs
"object_syntax_checks" (!) (hook name) vs
"check_objects" (MfD template)
"row create" (diagram/BS pass) vs
"row_creation" (hook name)
"set value" (diagram/BS pass) vs
"set_values" (hook name/MfD template)
"check consistency" (diagram/BS pass) vs
"consistency_checks" (hook name) vs
"check_dependencies" (MfD template)
"undo_set" (diagram/BS pass) vs
"undo_sets" (hook name) vs
"undo_values" (MfD template)
It's probably not possible to bring all of these into line, but
my gut feeling is that the documentation (the flow diagram)
should perhaps be tweaked to match the public interface (the
hook names). And it ought to be safe to adjust the MfD template
framework as well.
Comments?
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
