On Wed, 2005-01-12 at 20:54, Robert Story wrote:
> DS> It's simpler to understand the detail of each individual step,
> DS> but it's much harder to understand how it all fits together.
> DS>
> DS> I think the existing model is much easier to understand, but needs
> DS> more thought as to the close-in detail.
>
> Isn't "more thought as to the close-in detail" the same thing as "[hard] to
> understand how it all fits together"?
No.
It's easy to grasp the overall picture with the current framework:
- check the request and get everything ready
- actually make the assignment
- tidy up afterwards
with suitable error handling after the first two.
That's "understanding how it all fits together".
[The Reserve1/Reserve2 split is something of an
aberration, but doesn't complicate things excessively.]
It is *not* easy to grasp the overall picture with the baby_steps
model - witness the need for the flowchart. Having to come to
terms with a ten-stage pipeline for a successful request is a
much steeper learning curve, IMO.
I view this flow chart as an extremely useful refinement of the
general structure, filling out more detail of exactly what is
involved at each stage - "the close-in detail".
But it's not particularly clear as a basic model.
As part of That Bloody Book, I've included a discussion of
various different approaches to SET processing, showing exactly
why any simpler framework is fundamentally flawed. I end up
with the five-stage R/A/C model, which then maps very neatly
onto both the AgentX protocol, and the Net-SNMP behaviour.
And that's discussing things in abstract from first principles
(though coloured by my experience here, I will admit!)
There is a reason why the AgentX working group came up
with the model that they did.
I don't know how I'd handle the same discussion based on the
baby_steps framework. Well actually, I do - I simply
wouldn't bother, because I don't think it would be helpful.
> DS> So the current framework of "baby_steps on top of R/A/C" is a
> DS> reasonable one. Switching to "R/A/C on top of baby_steps" would
> DS> mean adopting the worst bits of both approaches.
>
> The problem is that "baby_steps on top of R/A/C" is a hack because it is
> expanding the state diagram.
I don't see that as a hack - I see that as a refinement.
> However, "R/A/C on top of baby_steps" could be
> done much cleaner, because it would just ignore states it didn't need.
Whereas I see *that* as a hack, since it means doing some tasks
in the "wrong" step.
> DS> But you snipped the other example - of locking some resource that
> DS> needs to be released as soon as possible. Having to leave that
> DS> locked throughout the full processing of the SET request is *not*
> DS> an acceptable solution IMO.
>
> On Mon, 10 Jan 2005 15:02:38 +0000 Dave wrote:
> DS> But what if the only way to check particular values does involve
> DS> allocating resources? Perhaps ..... to
> DS> lock some shared subsystem? ..... Without some form of
> DS> 'free_only' step, such resources would need to be retained until
> DS> the 'post_request' step.
>
> And the problem with that is...??
That the lock might well need to be released in order to actually
set the new values.
> Note that in the error case, post_request is
> the next state.
Yes - and in the non-error case, it'll be undo_setup (release the
lock) then do a whole lot of other things, then call post_request
(release the lock again???)
> (Besides which, if you were going to close the db in the very
> next state, why not just close it at the end of the check state?)
And if there are two cooperating objects (implemented using
separate handler chains)? The first one can grab the lock,
but this shouldn't be released until after the second one has
finished making it's checks.
So the first opportunity for the first object has to release
the lock would be in undo_setup.
> DS> RS> I still don't see what another mode buys you that can't be done
> DS> RS> with the existing modes.
> DS>
> DS> Anything that needs to be done somewhere after the 'check_values'
> DS> (or 'undo_setup') step regardless of success or failure, but must
> DS> be done before the commit step.
>
> Ok, now I'm *really* confused. I thought you were talking about a free only
> state, but now you are talking about a state that happens before commit?
No - I'm talking about an *action* that needs to happen:
a) after a successful check_values step, but before the commit
and
b) after an unsuccessful check_values step
These are mutually exclusive - only one will apply to any given request.
But the same action would need to appear in two steps - 'undo_setup'
and the (missing) 'free_only' step.
> DS> I think it's a mistake to say that "we can't think of anything,
> DS> so no-one will ever need this" - we've got bitten by that before.
>
> And I think the new handler parameters and data structures are sufficient
> for additional flexibility.
And I think you're wrong.
> DS> Particularly when this could be handled quite easily.
>
> I still maintain that it can be handled quite easily without an additional
> state.
And I still think you're wrong.
> Let's try another tack. What, exactly are the states you want to add,
> and where would they fit into the flow chart?
Two new states:
one invoked between 'check_values' and '(err && f1)', and
one invoked between 'undo_setup' and 'undo_cleanup'
i.e. in those two long "error lines' down the left hand side of
the flowchart.
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
