>>>>> On Wed, 12 Jan 2005 12:55:06 -0500, Robert Story (Coders) <[EMAIL
>>>>> PROTECTED]> said:
DS> I'd be particularly interested in hearing what Wes thinks about this.
...
My thoughts:
1) Robert's goal with the baby steps (as part of what was needed for
the MFD stuff) was to make it possible to write small constrained
pieces of code. From the admittedly little bit I've played with
it, I think he's accomplished that.
2) I do think that we need a better architecture for dealing with SET
processing than exists now. It is hard to deal with cross-module
problems. In part because there is not enough definition about
when to do what where. This is especially true for the testing
phase, where it is difficult to decide when to do certain types of
testing. The baby steps were designed to fix this and again I
think it did a good job, but again I haven't thrown a really tough
case at it. I know it handles column level vs row level
consistency checks, which is one of the more annoying things to
deal with.
3) There are two options forward:
A) leave the existing 6 state diagram in place as is and map the
baby steps to it.
B) put the baby steps (or other agreed upon architecture) in place
and map the older steps to spots in the newer one.
There are disadvantages and advantages of both (sigh):
A [leave existing]:
Dis: doesn't allow modules all implementing the various
micro-defined steps to interact with each other and bail out
earlier together. Each modules steps within one of the original
steps is self contained and thus must undergo multiple
transitions internally even though it may eventually bail because
another module ran into an error. Early error detection means
early bailout from everyone.
B [new but mapped back]:
Dis: Unfortunately, mapping the old states back on to the newer
diagram means that the older state code will invariable be doing
things "at the wrong time". Thus, unless all the code changed
[forget it] to accommodate the new state mechanism, the error
conditions it would have to handle for stuff happening out of
place still need to be dealt with.
My gut feeling (which is actually thought out over the year+ that
Robert has been working on this stuff) is that B is a better way to go
still. The advantages of being able to bail out early is a good
thing, and the advantage of having the modules interact better with
respect to errors is a good thing. I think that outweighs the
potential disadvantages which I think can be overcome with careful
thought about where to map the old states too and documentation
describing what has to be done at each step to deal with problems (and
the documentation is already well underway).
So, I think B is the right choice.
Robert> I think a mechanism to have the agent use a new state map will
Robert> go in, but as a result of this discussion it could be any one
Robert> of:
Robert> a) a full replacement, w/a helper for existing modules
Robert> b) an addition, with an ifdef to switch between the two. default tbd
Robert> c) an addition, with the internals made generic so that it can
Robert> be determined at runtime, or perhaps both be used simultaneously.
Robert> I like c, but I don't know how easy it would be to pull off...
[this selection only makes sense if B above is chosen in the first
place, right?]
I'd actually vote for a, or better a with mappings between baby_steps
to current states directly. I'm not sure a helper is needed, but I
say that without having analyzed things much. I don't think adding
the complexity for c is worth it. I think (b) will probably be nice
during a transition, *if* it could be done cleanly (or else it's not
worth it either).
--
Wes Hardaker
Sparta
-------------------------------------------------------
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
