Fellow Avaloners,
Greetings and salutations.
Warning: This is a LONG email. This is the sort of email you should
print out and take with you to a nice quiet place and ponder over. :)
We've seen a lot of discussion about Avalon's mission and future.
This email is an attempt to not only summarize those points, but also
better frame the real arguments which are being made. I have tried to
be objective in every way possible.
I am sending this message to both the developers mailing list and the
users mailing list because I value the feedback of both groups. I
hope that the consensus which we build will come from both users and
developers.
Okay, here we go...
Let's start by separating concerns. :-)
I am going to describe what I believe to be the issues central to all
the debates here in Avalon in two ways. Yes, essentially, that means
I'll be repeating myself, but I believe the points raised have
multiple aspects and by viewing more than one dimension, we'll get a
better understanding of the problem.
All of this resolves around the question of "What is Avalon's
mission?" The two ways I'll approach this are:
1. Community Scope
2. Framework Specification
Let's start with community scope.
Should Avalon be a sort of "umbrella" project for multiple container
implementations or should there be a single Avalon platform and/or
product?
This question is really at the heart of a lot of the recent
discussions. Traditionally, Avalon has been about the framework API.
Anything not in the framework has been up for grabs for the container
implementer. The great advantage to this approach is that we end up
with a lot of diversity and freedom to explore a number of different
solutions. This means we have specialized containers for various
scenarios. You get to use the right tool for the right job.
At the same time, the approach has left us with incompatibilities
between our own containers. You have to have a very good
understanding of Fortress, Merlin and Phoenix to write an application
which will run cleanly under all three. This puts a strain on both
our developers and our users. I can't even begin to count the number
of times someone has asked, "What container should I use?" and the
question is absolutely warranted given the situation.
I can see how someone may not be concerned with these
incompatibilities. For example, Cocoon still uses ECM. As long as
ECM works for them, why should they be concerned that their components
don't work in Merlin (or whatever)? Why not just be pragmatic about
things and just use what works?
While this argument has merit, I believe it misses out on what Avalon
set out to deliver. I don't believe we intended on creating a
component oriented framework where reuse was a secondary
consideration. Seeking to rectify this situation seems (to me)
perfectly in line with our charter and mission.
Which brings me to the opposite side of the spectrum. Rather than
have Avalon as a home to any and all IoC containers and frameworks,
the Avalon community could focus on a single platform, a single
product, a single meta-data/meta-info description. We could unite
behind a single reference implementation container. It would simplify
our documentation, our efforts, and hopefully allow us to be more
effective in bringing a true IoC/SoC/COP framework to the world. If
nothing else, it would allow more component reuse and hopefully
dispel some user confusion.
Of course, this approach has is drawbacks as well. It leaves less
room for alternate containers and implementations. Competing ideas
may be sidelined and specialized containers perhaps harder to support.
We may not have the flexibility we now enjoy to solve problems our own
way. It would require everyone to agree on a single platform and be
willing to work on that platform.
Now, at one point I thought the problem was just as simple as this --
Avalon is either "IoC Central" or it's about a single product. But
then I began thinking of it in another way:
Framework Specification.
In addition to thinking about the differences in the scope of the
Avalon community, we can also think about the framework specification
itself. Instead of seeing two completely opposing sides, imagine now
a larger spectrum. At one end is our current framework (just the
avalon-framework-api.jar), on the other end is an entire container
reference implementation (something like Merlin). With this
perspective, we can see that a lot of the arguments align along this
concept -- what should be part of the framework?
In other words, what makes an Avalon container an "Avalon" container
or an Avalon component an "Avalon" component? It's a matter of
describing a specification or a test compatibility kit (TCK) which
defines what it means to be Avalon compatible. Leo Simons already
pointed out a lot of the issues surrounding a TCK and how it could
range from the simple (our current framework) to the complex (a
complete container spec).
I like using analogies, so here we go -- imagine the Avalon car
company. We decide we're going to make cars. Now we need to decide
on some basic specifications. These can range from the very flexible
(only requirement that it has four wheels) or the very specific (you
only get to choose the color). In a similar sense, this is what we're
talking about when we describe the framework specification.
At the same time, this is really the same issue as the community scope
issue. Under the Avalon umbrella scheme, the spec is only the current
basic framework API. Fortress, Phoenix, Merlin already all fit that
spec. Under the Avalon-as-one-product idea, the specification might
be much more strict and include things like meta-data, packaging,
standard extensions, etc. So really, it's the same problem, just
another way to describe it.
So we have two questions:
1. Community Scope: IoC central versus a single product?
2. Framework Specification: What is part of the framework?
All the debates and proposals are due to the fact that not all
Avaloners agree on the points of community scope and framework
specification. Those who favor a more flexible framework
specification want to ensure Avalon can be used in a multitude of
scenarios. One size doesn't always fit all. Those who favor a more
strict specification see the current framework as full of holes which
has allowed the current mess of incompatible components. Until we can
agree on these basic issues, there will always be competing agendas,
mixed signals, and unnecessary arguments over implementation details.
In a sense, Avalon has been suffering from 'identity crisis' for some
time now.
Most of us agree the status quo is not what we would like it to be.
That's not to say Avalon is in horrible shape. We have some awesome
containers and products already. But we all know it could be better.
Better for the developers. Better for our users.
At this point, I hope you have a clear understanding of the issues of
scope and specification. If you do not, please try re-reading some of
the latest email threads, keeping these perspectives in your mind. I
think you'll find yourself understanding both sides of the issue,
seeing the pros and cons of everyone's argument.
Despite all I've written so far, I still sometimes wonder, "Is this
even an issue? Are we just working ourselves up over nothing?" I
believe this is sometimes the case. For example, it's very easy for
'implementation creep' to enter into these discussions. That is, when
discussing a specification, naturally one begins to think about
implementation details and sooner or later we find ourselves arguing
about implementation issues while we still haven't even agreed that a
specification should exist! At times like this it's easy to argue
arou
