Al Sutton wrote:
Brian,
Dependencies can be reduced to simple ordered lists unless there is a
requirement for two plugins to be run in parallel (which is pretty
rare), or you have a circular dependency. Reduction of dependency
graphs is something I've come accros dependency declaration handling
several times in my last couple of decades of development, and in all
that time I've not seen a dependency evaluation system which couldn't
run as an ordered list as long as you state it can't have parallel
tasks or circular dependencies.
I know that they can always be reduced to an ordered list, but that list
is not always the same depending on the graph. Having written Savant, I
know quite a bit about dependencies and graph traversal and in my
opinion it is not a suitable solution for this problem. There are too
many root nodes and traversal edge cases. Not to mention plugins would
eventually have to be knowledgable about most plugins in order to reduce
traversal complexity and guessing.
Plugins will have to define their dependencies if they want to be
handled correctly, so if G needs to be run after D then D is a
dependancy, and if the author of G does not declare it as such then
that is an bug in plugin G. Similarly if B needs to be run after G
then B needs to declare G as a dependency.
Right. That's my main point. Otherwise, they end up being root nodes in
the graph and traversal is based on parse order and that means it could
be different each time if the parse order changes. When you have four
root nodes, which goes first? That's a tough question to answer and
guessing means it could be right during one pass and wrong during
another, especially as you introduce other root nodes.
If you are talking about optional tasks then you then enter the more
complex world of mandatory and optional dependencies (e.g. G should be
run after D if D is configured, but if D isn't configured then we
don't need to put it in the list). That is something to be handled on
either a second pass once all of the configured plugins and their
dependencies are known and have an initial order. During the second
pass the entries are shuffled if neccessary to satisfy the option
dependencies.
Nope, I'm assuming everything is mandatory. I'm just assuming incomplete
graph knowledge up front and having to make choices in a sort of fuzzy
manner.
I understand there are situations where the user may want to run G
between D and B and they can't modify B to declare G as a dependency,
but thats where the manual configuration options come in. If a user
wants to specify an order they can do so and the core should only
verify the order satisfies the dependency requirements.
Agreed. But the trade off of complexity here isn't worth it it seems.
The configuration is minimal and the complexity of a dependency
management graph and traversal seems to be too much. Furthermore, it
adds a bit of "magic" that users might find disconcerting. Savant on the
other hand is based purely on this "magic" and integral to the system.
This means users need to fully understand it to use Savant. Struts on
the other hand would probably suffer from this to some degree. I would
think it would be like the JBoss infrastructure. Some folks would love
it because of all its dependency management coolness but most folks
would hate it for the complexity and inability to quickly figure out
what the heck is going on.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
