Given the exposure Avalon's problems get here, I figure I'd open my
mouth
on this subject and spew out what I learned from the infighting we had
there - because, make no mistakes, fighting is the correct word for what
went on. (And thank God it's over and done with.)
I think everyone here confuses two things: Action and intent. You can't
codify good or bad behaviour based on actions without building an entire
legal system. What matters is the intent behind the actions.
For example, should core services in Cocoon be abstracted? Yes,
absolutely.
I think it is a good architectural pattern that will help you manage the
code and really think about how Cocoon is held together.
Should people be allowed to plug in their own versions of core services?
Yes, absolutely. This is how a program evolves safely: Try out the new
idea
in a separate branch.
So much for the actions, but what about the balkanization? Well, this is
were intent comes in. I don't think there's any danger if the new
branches
are started with the intent that the *concepts* developed there should
be
merged back into the core, if the branch proves better. I also think
that
the intent must be not to lock yourself into a specific implementation,
but to see the branch as something whose best aspects should be picked
out
and placed into the core.
This is the risk: Developer A has a need to fill. That need can be
fulfilled by writing a new version of some core Cocoon service. So A
does
that. Problem solved. Now A wants this implementation to be official in
the sense that it should be included with the Cocoon default distro.
And then all hell breaks loose. 50% wonder where this new chunk of code
came
from, 10% thinks it is useless, 99% don't want to maintain it, 99.9%
admit
to having no clue how the adoption of this new version will affect
future
development, and the last 0.1% percent is just kidding himself.
By now A has significant investment in the code - it is running at his
clients.
He can't just drop it. So he fights even harder to get it into Cocoon.
Things
really start to turn to shit now, community- and technology-wise.
The solution is to adopt this as a mantra: "You get what you need, not
what you
want." I'll describe below how this maps to the current situation.
-oOo-
So what about this rule-based flow processor? I think you're attacking
the
wrong problem. Before we ask ourselves whether it should be allowed in
Cocoon, we have to ask ourselves what problem it solves that can't be
solved
with the current flow. Otherwise we get it completely backwards.
Whoever wrote the rule based flow did so to solve a problem. But if we
start talking about whether to adopt the rule-flow before we start
talking
about the problem that prompted its creation, then we're locking
ourselves
into one solution - the rule-flow.
Do you see *why* this is backwards?
A solution has been presented: The rule based flow processor.
But (1) what is the problem it solves? And (2) why do we need the rule
based
flow processor to solve it?
Once (1) has been made clear, perhaps we find that it can be solved with
the
current flow processor. Then we can do so and save ourselves a lot of
code
maintenance. So you'll get what you need (a solution to the basic
problem),
but not what you want (a rule based flow processor).
Hunsberger, Peter wrote:
> As I discussed with you when the flow sitemap integration discussions
> where in full swing I do have a long term agenda (XSLT managed flow)
> and I would like to see a way of including it in Cocoon without
> breaking existing functionality...
This is the wrong approach.
Peter, you don't want XSLT managed flow. What you want is a solution
to the problem that you have decided that XSLT managed flow is a
solution for. (Did you follow me there?)
You have a problem. You think that XSLT managed flow is a solution.
You therefore try to get XSLT managed flow into Cocoon.
Instead:
You have a problem. Explain it. Say that XSLT managed flow is *one*
possible solution. Maybe we can find a one-line change in Cocoon
that will solve your problem without adding a whole flow implementation.
Isn't that better?
You get what you need (a solution) but not what you want (XSLT managed
flow). And we avoid adding yet another implementation of core services.
-oOo-
OK, so why do we risk balkanization?
Obviously and embarrassingly, it is much easier to code up a storm than
to talk to people and do the give-and-take thing in order to reach
consensus. This has nothing to do with coders being asocial. This is
just the way the world is.
And *that* is the risk with abstractions. It means that the cost for not
talking to your peers drop. And that was what happened in Avalon. Thus
we ended up with small islands of developers who simply put did not
trust each other.
So abstract and plug away, but never stop talking to each other. Be
ready to drop your specific solution for another one that solves your
problem.
Finally, some academic theory:
In negotiations, people have a goal and a position. The goal is what
they
really want. The position is what they say they want. To illustrate,
may people think that President Bush's goal for invading Iraq was oil,
and that stopping WMD was just a position.
Another example: My position may be that abstractions are good, but my
goal may be to replace some Cocoon core service with my implementation,
because it would help my business.
Obvious conclusion: Everyone in the community has to be open with their
goals. Otherwise negotiations (discussions) become much, much harder
since
nobody really talks about what they really think is important and end up
discussing positions like "is abstraction good?" which is just a total
and utter waste of everyone's time. I bet nobody in this thread really
cares about that topic.
To top this email off: My goal is that Cocoon should consolidate code
and firm up contracts. For example, I think that it was great to drop
the
pluggable request factories. Let's stay away from having 10,000
configuration
options that interact in ways that nobody can keep track of. (Yes, that
would help *my* business, but I think it would help yours, too.)
/LS
PS: If I have it all wrong and "balkanization" means more slivo for
everyone, then, boy do I have egg on my face!
