Brian Pontarelli wrote:
Al Sutton wrote:
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 they are all root nodes then it does not matter which is processed
first. If one of the nodes has a dependency on another being processed
before it then it needs to declare it (and thus can't be a root node),
or the plugin implementation has a bug, if they do not depend on each
other then they are four separate plugins whose order of execution does
not matter, and therefore there is no right or wrong solution. Therefore
if A,B,C and D and they are all truely root nodes it does not matter if
the order is ABCD or DCBA, because are non-dependant.
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.
And the "fuzzyness" is eliminated by the declare or die rule. If the
plugin implementor does not declare it's dependencies correctly then
failure by the core code to create the correct set of pre-conditions is
actually a bug in the plugins dependency declarations.
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.
I don't see the magic or the complexity. Plugins declare their
dependencies, the core code orders the execution list, and all is good.
If they want to use conflicting plugins which require a specific order
they can add some configuration information, but in most cases this will
most likley not be neccessary.
Still, it looks like the plugin dependency idea is a non-starter anyway,
so I guess it's on to other things.
Al.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
