avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: One Container Revisited
Date Mon, 01 Jul 2002 14:47:56 GMT


> From: Adam Rossi [mailto:adam.rossi@platinumsolutions.com] 
> 
> I have been talking to a lot of people about Avalon. I know 
> damn good Java developers that look at it and cannot figure 
> out what is going on, and walk away. These are senior 
> software engineers that are well respected. That is a 
> problem. If there are some Avalon developers saying one 
> container, and other developers saying three, make it one. If 
> some want simpler organization, and others more complex, 
> choose the simpler. Please.

Not that easy. Thing is, the three-container solution was/is the 
simpler one, if you ask me.

The problem is this: Suppose we do a very very simple container.

Now, do you add features to it?

If you do, you increase complexity and the container is not simple 
any more.

If you don't, all developers will do so individually in their own
projects and you have duplication of effort.

So what do you do? Suppose you add features.

As the container gets more and more feature rich, it is harder and
harder to get started with it (higher barrier of entry) - assembly 
descriptors, metainfo, etc. etc. At the same time, those same assembly 
descriptors are required by users of the container to avoid duplication 
of code, and above all, when you know how to use them, they *increase* 
simplicity.

So what is simple for a beginner may be a nightmare of complexity
for the person building a BIG application with Avalon. What is simple
for the seasoned developer and scales well may seem like a monster 
of complexity for the beginner.

The three-container solution was to have one container that was easy to 
start with. Then, as the user felt a need for more complexity - more
features
in the container - he could switch to the next more powerful container
instead of introducing feature creep. The components would still work,
but there would be a bit more complexity for the user to deal with in
exchange for more container features. A bit more committment to the
Avalon way of doing things in exchange for more magic in the container.

And to this comes the committment threshold. As you start using metainfo
and everything, you committ your app more and more to the Avalon way of
creating applications. Maybe that isn't possible. Maybe you can not
fulfill the requirements a sophisticated container puts on your system
design. Again, the simplest of the three containers would come with 
minimum requirements (no assembly spec required, etc...).

So let me ask you - how would you solve this problem?

/LS


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


Mime
View raw message