On Fri, 2005-01-07 at 16:29, Robert Story wrote:
> 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.
Fair enough. I think this would be worth doing.
It probably doesn't really matter whether the default is to include such
code ("It's easier to delete code than to add it"), or to exclude it.
But I think the overall framework needs to be able to cope with such
requirements.
On reflection, I think you're right to suggest handling this as part
of the 'commit' step, rather than in the 'irreversible_commit' step.
> (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.)
Hmmm.... I'm not sure I understand that last comment.
It would move some of the processing into the 'm2i' files, perhaps.
But why would it affect the get/set files - other than removing
irrelevant code. I certainly don't see how it would result in
"one big function" in these files.
Unless I've completely misunderstood you here?
> 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.
But is there any way of generating such a hook?
I haven't looked through the mib2c-conf.d files in detail, so there
may well be some variable that can be set in order to activate this.
That would be a perfectly sensible way of discouraging undo-able
commits.
But there *are* situations where such UNDO handling is not possible,
so the MfD framework needs to be able to handle irreversible commits.
My concern is that this may currently involve fiddling with the
interface.c file, which doesn't feel a sensible way to go.
> 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. ;-)
Humph. I'm not sure that's an acceptable response to a discussion
about possible design flaws :-)
> 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.
I think you've misunderstood me. I'm not proposing that the
'irreversible_commit' hook should replace the existing 'commit' hook.
I'm suggesting that the MfD framework probably needs to include
an 'irreversible_commit' hook as well. Quite possibly disabled by
default, but there ought to be some clean way of generating this.
> 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.
Except that it's not a full equivalent.
Because it's not "free-only" - it's "free-and-undo-and-commit".
If you're designing a basic architecture (i.e. thinking of the
abstract baby_steps model, rather than the MfD use of it),
you really need it to be as flexible as possible.
As it stands, there is no way to handle errors in the 'check_values'
or 'undo_setup' steps, without reverting to ugly workarounds such as
setting flags (which would need to be done in *both* 'undo_set' and
'irreversible_commit', BTW)
> First off, check_values should not be allocating resources
But what if the only way to check particular values does involve
allocating resources? Perhaps to do some database lookup, or to
lock some shared subsystem? And suppose that these would naturally
be released in the 'undo_setup' step? Without some form of
'free_only' step, such resources would need to be retained until
the 'post_request' step.
I think you're probably right, in 99% of cases, there probably
won't be much call for such a mode. But if the baby_steps model
is intended to be a general-purpose framework, it needs to be
able to cope with that 1% of cases as well.
We need to try and avoid enforcing a particular model on the
people using this suite. If you think I'm wierd (Don't answer that,
Hardaker!), you should meet some of the other people out there :-)
> Second, commit and set both have their own undo functions. Any cleanup
> specific to those modes can happen there.
Yes - that's fine.
I'm just saying that it's a flaw that there isn't something similar
for the FREE-style steps as well.
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
