(OK, here's some stream-of-consciousness - SoC - writing.) All,
what Nicola Ken wrote in his latest email http://marc.theaimsgroup.com/?l=avalon-dev&m=102467486019040&w=2 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. /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
