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
around in circles and never get anywhere. That's partly because we
aren't addressing the basic problem first and moving forward one small
step at a time. Therefore, I do believe we have some real issues to
discuss that are important, but they can be easily lost in tangents
and details.
With that in mind, let's risk a look at a couple "implementation
details" -- specific proposals from the last week or two. Only this
time, let's look at them under the light of our more basic, more
abstract, questions:
Niclas's Unifying Vision
Basically, Niclas's big argument is that our components don't work
cross-container. As far as he is concerned, the framework is
incomplete because it allows for these sorts of discrepancies. He
would like to extend the framework to include a more complete set of
container-component contracts so that if you followed this
specification, your component would work in any true
Avalon-compliant container. This would require a TCK or two which
would help lay out these rules.
Notice that this idea does not limit us to one container. As soon
as the TCK were in place, we could have all sorts of containers --
enterprise ones like Merlin, embedded ones like Fortress. The
important part to this vision is a fairly strict framework. His
current promotion of Merlin is simply because there's already a
lot of momentum behind it. Additionally, it may be easier to start
on one container and then branch out from there.
So, in our spectrum of things, Niclas's vision falls fairly strongly
on the strong framework specification side, but still allows for
multiple containers once the TCK has been written.
Stephen's Total Domination
Stephen's proposal is actually not very different from Niclas's
vision. The differences (if any) perhaps rest mostly with what
should be included in the TCK. Stephen feels that there should be a
single component model design which would (in my eyes) be heavily
influenced by the Model Driven Architecture paradigm. The basis for
this model can already be seen in Merlin today. Moreover, this
strict TCK would lead us to a reference implementation container
which would most likely evolve from the current Merlin code base.
Thus Stephen's approach, like Niclas's, is strong on the framework
specification and also very strong on the single product idea.
Stephen has informed me that his proposal does leave room for other
containers as long as they too follow and pass the TCK.
Berin's Zen Framework
Berin has already begun work on his Zen framework over at
d-haven.org. Berin's approach would also lead to easier component
reuse, but this would mostly be due to a more forgiving and
extensible container (I hope I'm getting that correct). In the end
this new container framework should be able to support the features
of our current crop of containers but not be so constrained.
In this case, we would end up with a much looser framework
specification (i.e.- "No Framework") but still end up with a single
platform. That is, this Zen Framework would supercede our existing
Avalon framework and containers.
Leo's Container Aspects
I'm still getting up to speed on this one, so Leo may need to step
in and clarify, but essentially, this approach is to build a new way
to assemble a container from multiple "aspects" or "facilities."
These container parts would be independent of one another as much as
possible and easily replaced or extended.
The aspect approach certainly allows for multiple containers, but in
effect, they would all be various combinations of aspects, component
handlers, and facilities. If I understand correctly this would also
allow for more flexible framework constraints if one so desired --
perhaps even "pluggable" framework specifications. In this way,
support could be added for the existing Avalon framework and
container nuances while leaving the option of alternative specs
open.
Keeping the Existing Containers Approach
Finally, another alternative is to simply maintain our current
course and offer support for Fortress, Phoenix, and Merlin. In this
case, we would definitely be supporting multiple containers, though
there is certainly interest in providing better cross-container
support. Of course, it is somewhat difficult to see exactly how to
do that without resorting to an approach similar to ones listed
above.
Other ideas of course exist, but what I wanted to do here was give a
sampling of the proposal presented so far and see how they align with
the
ideas of community scope and framework specification. I'm not doing
this so that we can hash out the merits of each one, but instead to
see how answering the more fundamental questions about Avalon's
mission makes the issue of which proposal much more academic. At that
point, the remaining proposals would all be dealing with implementing
our mission, not inventing it as well.
See, separation of concerns. :)
Now, some final words:
We care about our users. No one wants to leave users high and dry as
developers wonder off perusing some holy grail. Any change in our
mission or any new roadmap would have to provide for the users of all
existing containers. Such provisions are not hard to add to any of
the existing ideas, so no one should get too worried that support for
your favorite component or container is going to disappear. Even if
we should all decide tomorrow which path to take, the existing
containers would remain (though perhaps without further development)
until a proper replacement existed.
So, you've put up with me this far. Now what?
Well, that is exactly the point. I feel before we can accept any of
the proposals outlined thus far, before we can adopt any sort of
roadmap, we need to have consensus on these basic issues of Avalon's
mission, namely the matters of community scope and framework
specification. In order to come to a consensus on this, I propose:
* We offer a period of up to one week for discussion of this matter
This can include some discussion of the merits of the various
proposals; however, please avoid 'implementation creep' as much
as possible. Please state your feelings about the more general
matters of Avalon's mission. You may consider posting an email
which answers the following questions:
1. Why do I use Avalon?
2. What do I feel Avalon's mission to be?
3. Where do I see Avalon by the end of 2004?
4. How do I feel about Avalon as an umbrella project vs. a single
product?
5. Should there be a formal framework specification?
6. If so, what should it consist of?
* If a clear consensus has not been reached after one week, a vote
will be held. The exact nature of the vote will depend, to a
degree, on the proposal discussions. Foreseeable items include:
- Avalon as an umbrella project vs. a single product
- An effort to define a TCK
- Vote on a specific proposal listed above
I appreciate your patience with me. I hope that I have clarified some
ideas here and opened some minds. I may follow up with some further
emails exploring the "why's" behind each proposal and a better break
down of the various pros and cons. While I'm not certain we can please
everyone, I do believe we can come to a common solution and move
forward in Avalon without every again worrying about our mission, our
vision, or the road ahead together.
Thanks,
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
