avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject [ann] what I am going to do
Date Wed, 07 Jan 2004 11:49:55 GMT
Hi gang!

Introduction
------------
Based on the recent "Where do you want to go?", "How do we get there?", 
"Feeler question: What is Avalon's mission?", "Avalon's Image" and other 
threads, but mostly based on my own multi-month evaluation of avalon's 
direction, I felt I needed to rethink my relationship to the avalon project.

I've considered every option available to me thoroughly and consulted 
with several peeps about each of them. In conclusion...

What I'm going to do
--------------------
I am going to build a container from scratch. Actually, I've already 
started.

Where I am going to do it
-------------------------
I've set up a sourceforge project:

     http://jicarilla.org/

Why I am doing it
-----------------
This is the container I need, and this is the easiest, fastest and least 
offensive or intrusive (for others) way to develop it.

Furthermore, I'm pretty annoyed by the fact that the IoC/COP world, 
which *should* be about *portable* and *reusable* components, is 
hindered by a dozen incompatible implementations. Actual portability of 
code is worse than with, for example, a static factory design, EJBs, 
etc. I'm determined to solve that.

Why I am not doing it here
--------------------------
Like I wrote before...

1) merlin is great for users;
2) there's a lot of development going on surrounding merlin;
3) merlin is not so great for some developers, like me;
4) merlin is not so great for some use cases, like mine;
5) I myself am not capable of changing #3 an #4 without impacting
    #1 and #2;
6) I believe merlin needs to be the future for avalon, and active or
    radical new development around fortress or any other codebase would
    be bad for avalon as a community.

"This inevitably leads to the logical conclusion that" there is no way 
for me to build the container I want in the way I want, here, without 
causing negative side-effects to the avalon development and user 
community (and thus the ASF as a whole).

Why I am not doing it somewhere else
------------------------------------
Similar reasons.

My position at avalon
---------------------
Nothing changes, really. I will stay committer, pmc member, and 
generally vocal person. I will do no more or less development on merlin 
or fortress than I have in (roughly) the last 6 months (which isn't 
much); and the same goes for all the other codebases (which is a bit more).

I'm going to stop voicing my opinion on merlin though unless explicitly 
asked for it.

Can others participate?
-----------------------
Sure, everyone is welcome. But for now, I suggest everyone evaluates 
avalon-merlin, avalon-fortress, picocontainer and nanocontainer first 
(in that order, perhaps) and participate there; make sure neither of 
those projects fits your needs. This because the jicarilla codebase is 
still very young and in a state of constant flux.

Cross-pollination, opinionisms, advertising, etc
------------------------------------------------
I will use my own judgement in figuring out when it is appropriate to 
mention something about my progress here, *unless* enough people tell me 
not to (in which case I promise I will shut up).

So what am I doing?
-------------------
Here's my planned feature list:

* The 'standard' stuff
     * compact
     * fast
     * secure
     * reliable
     * extensible
     * modular
     * performant
* It is going to be compatible on a component level (as in what
   components it can run) with
     * core avalon-framework
     * avalon-ecm
     * avalon-fortress
     * avalon-phoenix
     * picocontainer
     * springframework
     * xwork
     * loom
     * dna
     * eob
     * keel
     * possibly others
* It is going to be compatible on an interface level (as in thin
   wrappers will be available around the container code to serve as
   drop-in replacement) with
     * core avalon-framework (ServiceManager, ComponentManager)
     * avalon-fortress
     * picocontainer
     * springframework
     * possibly others
* It will be able to integrate other component solutions through
     * jndi
     * jmx
     * altrmi
     * possibly soap
* the core will be "code only", meaning that there will be no dependency
   on any kind of non-java file.
* the core will be conservative about threading, meaning that any
   usage of multiple threads will be pluggable.
* the core will be environment-friendly, meaning that it should be
   simple to use in different environments.
* support code for use of the core inside several environments will be
   provided:
     * standalone (CLI)
     * standalone (GUI)
     * standalone (daemon)
     * embedded (servlet)
     * embedded (ejb)
     * embedded (avalon component)
     * embedded (picocontainer)
     * embedded (fortress)
     * exported (jndi)
     * exported (jmx)
     * possibly: embedded (JBoss)
     * possibly: embedded (merlin)
     * possibly: embedded (phoenix)
     * possibly: embedded (loom)
     * possibly: exported (soap)
     * possibly: exported (altrmi)

I've got the basic container in place, and some proof-of-concept 
materials like avalon, spring and picocontainer integration is in place 
as well. I've also set up all the 'support architecture' like mailing 
lists, wiki and build system that I thikn I need.

What am I building it for?
--------------------------
I'm going to use this container as the basis for developing a complete 
http server from the ground up (I've always wanted to write my own http 
implementation).

On top of that I will build a media server. I will also develop a 
multimedia client to connect to the media server. These latter two will 
likely not be open source, but the http server will be.

How am I building it?
---------------------
The architecture borrows heavily from picocontainer, but makes many 
compromises in order to make it simpler to support the compatibility and 
integration goals (and it contains some things I consider improvements 
on the basic picocontainer design). The architecture is based on 
inversion of control, seperation of concerns, seperation of interface 
from implementation and (contract-based programming). Furthermore, 
extensions will be available to support aspect-oriented programming and 
event-based programming.

Code development atm doesn't quite follow an XP or Agile process, but 
there is a focus on testing, incremental development, "doing the 
simplest thing that can possibly work", use case analysis, etc.

-- 
cheers,

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett



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


Mime
View raw message