avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject [RT] Spearhead
Date Tue, 06 May 2003 08:12:32 GMT
[RT] are Ramdom Thoughts.  This is a tradition in the Cocoon community. 
  RTs are basically long and thought-provocing mails with new project 
propositions, that are discussed and scrutinized at length.  One 
distinguishing characteristic about RTs is the complete and utter lack 
of consistency with respect to quality: some are pure crap, others are 
pure genius.  Even the original author of a RT is not sure which 
category any given posting falls into at the time it is issued.  This 
posting is no exception.

I've taken snippets from many messages over the past few weeks. Unaware
co-authors include the Peters, Leos, Berins, Noels, Stephens, Gregs, 
Sams of the world. We have to get our act together. We should start on

Broad Support
The Avalon developer and user communities need to be on board. However,
we should also not lock ourselves into a non-consensus stalemate. At
some point in time we should say "okay, lets just sandbox this thing"
and convince by code instead of words. We're all better at writing
software than at design virtual communities. We don't *need* unanimity.

Supporting existing stuff
We are not going to get in the way of existing containers. Only when we
have solid code which actually allows a snap-in replacement of those
containers are we even going to bring up any kind of merge and/or
maintaince mode talks again. The key here is that we are enabling new
developments while sustaining and supporting existing materials.

Spearhead is not about killing off existing stuff.

Leveraging existing stuff
Each container brings something to the table. One needs to look at the
value of particular implementations and consider what those respective
implementations deliver, and to respect that all of them offer something

The idea should be to learn from BOTH of them, and design a NEW
micro-kernel based upon those experiences. I don't believe that it is
either necessary or helpful to keep defending [any particular
container], or trying to sell it in the context of future work.

In an ideal world, all of the committers and interested parties could
sit down and calmly critique the relative merits of each container. It
would be helpful to build some common ground first, and then do
that comparative critique.  That critique should not be a general one,
but facet-based; looking for those successes and failures in each
container that will help guide Avalon 5 development.

We have to get past the egos, stop looking at a macro comparision of the
containers, and get down to the heart of what works, doesn't work, or is
simply different for one reason or another.

Leveraging recent developments
There are new developments in various areas which will allow us to do a
much better job. They make us itch to try the same basic thing once

The rise and increased acceptance of extreme programming methodology
will make life easier. The test-first paradigm will solve many issues,
like compatibility provision. Coupled with the refactor mercilessly
paradigm this will allow us to be radical yet maintain evolutionary

The crystalizing of recent revolutionary technologies like interceptor
architecture, AOP and event-based systems, along with tools to support
them allow us to merge the best parts of the dynamic and static parts to
the container equation.

Finally, we have tools like IDEA, maven, gump, JIRA. They will help in
better organising our new projects, making it possible to
(like interceptor
architecture, AOP, avalon-framework based applications, event-based
systems, scripting tools for java, much larger developer pool, much
more detail of usecases, extreme programming, refactoring, many new
container developments..........). Those make us itch to try the same
basic thing once more, and will allow us to do a much better job.

We have much more experience with test-first setups now. We have tools
like IntelliJ IDEA, maven, gump.

Implementation Keywords
KISS. IoC. SoC. In/Im Separation. Test. Refactor. Document. Microkernel. 
Interceptor. Meta. Abstraction. Isolation. Service management platform. 
Runtime-pluggable container service. Manageability. Containment profile. 
Component profile. Declarative interaction. Bundle specification.


- Leo

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

View raw message