avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject [RT] Avalon == Jakarta Architecture Labs (was: RE: avalon is not a risk dependency)
Date Sat, 22 Jun 2002 13:27:10 GMT
(OK, here's some stream-of-consciousness - SoC - writing.)


what Nicola Ken wrote in his latest email 


about how Avalon is percieved from the outside was for me
another confirmation of what I have been hearing/reading
about the downside of Avalon.

I think what he writes should not be ignored, but rather
that each committer should think about it. Yes, we are good,
our framework is the best, but when one of our potential users
even goes through the effort of pointing out to us what
he percieves to be the faults with our framework instead
of just silently ignoring it, that email should be a treasured
gold nugget.

Now, one conclusion that I have reached is that positioning
Avalon as the "Apache Server Framework", with re-usable
components is just a total impossiblity, given reality
as I know it. We can, however, be something else and be
quite successful at it.

Let me explain. 

If anyone has done game development on Windows, you have
probably heard of or come in contact with something called
DirectX. That is basically Microsoft's hardware abstraction
layer for games development. It provides a single API for
3D, 2D, sound, multiplayer, etc. across all Win32 platforms.
This API has evolved - DirectX9 is vastly different from
DirectX1 - and game developers have kept up. Now, the important
thing is that, well,

    when Microsoft calls your DXJump(), you call
    DXQueryHowHigh ().

DirectX has wonderful backwards compatibility (I ran DX6 code 
on DX8 no problem), but this, and the presence of a migration 
path, only restates the above to:

    when Microsoft calls your DXJump(), you eventually
    have to call DXQueryHowHigh ().

This, I think, is the biggest obstacle against adoption of
Avalon. Commons dependent on Avalon? Forget it. They do not
want to have anyone from Avalon tell then to jump.

As we are at the top of the food chain (we're not dependent
on anything else), it is easy to lose track of this. No
matter how neat a migration path, no matter if we warn a year
in advance of changes - the end result is the same:

    When we say jump, they *have* to ask "how high?".
    Maybe not immediately, but sooner or later.

Because they are dependent on us, and we aren't on them.
When we change, we change the *architecture* of the dependent
projects. *Architecture*!

And that brings me to the subject line of the message.

We do a lot of design here. We think about how things
should be. We emit a little tiny package called framework.jar
with an absolute minimum of classes. Sometimes we change
the architecture completely, and this is a major revision.
This is more major than we think. (When we change Avalon even
the slightest, we are not just changing one parameter in
one function call, or replacing one class with another,
as we are changing the "Avalon" architecture, we are changing 
the entire way our users should view their application.)

Isn't that more the behavior of a "labs" type outfit?
A research outfit?

With all the changes and all the directions we're going
in - components, blocks, services, SEDA - I think we are
doing the Jakarta community a service by probing and scouting
and developing new architectures. We are, in fact, a Jakarta-Commons
for architectures (note the plural). We're just not like
Jakarta-Commons in that we come with no strings attached.
By our very nature (we deal in entire architectures) we are
very "high committment". Probably the most high-committment
of any project here at Jakarta.

We always strive for perfection, meaning that our record
of stability just plain *isn't*. But isn't there a place
for a giant sandbox type development of *architectures*, 
from which other projects may take the best parts?

Instead of trying to be the "do everything", the ultimate
dependency, the framework for *all* of Jakarta, we would
release framework 4.0, Excalibur 4.0, and then not consider
A5 an upgrade, but something entirely new. The A4 architecture
would still be 100% supported not as a deprecated product,
but as a 100% alive and kicking architecture.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message