Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3D1F70D6.4030607@apache.org>
Date: Sun, 30 Jun 2002 22:57:58 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: organisation of avalon subprojects
References: 
 <5.1.0.14.2.20020630190730.00a63020@mail.inspireinfrastructure.com>
 <1025466669.1725.19.camel@lsd.bdv51>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Leo Simons wrote:
...
>>Another issue with this is that doing this walls us off from the rest of 
>>Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in itself and 
>>utterly isolated. I want to see Phoenix-based apps on the front Jakarta 
>>page. That's the only way to spread Avalon through Jakarta.
> 
> another one is to get existing projects adopt avalon.

IMHO these will not solve the ivory-tower problem, because Avalon has 
never been a technical issue in Jakarta, only a political one.

You can bring a horse to water, but you can't make him drink.

 > Agree though.
> Problem: jakarta itself hasn't really got a use for "phoenix-based
> apps", just for active communities (to support a piece of software).
> AvalonDB or AltRMI (or ...., or ....) is *not* ready for 'top-level'.

Which means IMHO that they are suited to a kind of "sandbox".

>>As Pete C says, I think we should slim the Avalon project *significantly*. 
>>And now I am talking about some chainsaw-grade reduction.
> 
> I think any radical approach is bad. As I said before: evolution instead
> of revolution is what we need right now.

I think that you two mean the same thing ;-)

it would be an evolution from the code perspective, but a revolution as 
project organization, community and communication.

>>With MicroContainer a new possibility has emerged: All Avalon components 
>>previously in Excalibur can move to Commons.
> 
> cool; but do all of them fill all the commons requirments? (moving them
> there would, fa, mean no support from me on them as I have no time to
> involve myself in commons)

? I don't see the problem of having the code in another repository, does 
it really matter that much where utility code is?
Anyway, "All Avalon components previously in Excalibur" is a bit drastic 
;-)  , let's do it gradually.

> IOW: there's a theoretical possibility. That is what you ment, no?
> 
> 
>>So I see:
>>
>>1. framework
>>Avalon Framework interfaces and reference implementation.
> 
> I personally feel RI should be separate from impl, as if you can have
> multiple impls, people that have a say about spec should not have to
> concern themselves with the RI.

+1 The containers *are* our RIs.

>>2. containers
>>2a. common container code (metainfo, etc.)
>>2b. microcontainer
>>2c. fortress
>>2d. phoenix
>>Again, this is my 3-container approach.
> 
> 
> if a specification were to state a RI would have to provide a way for a
> component built to the specification to be run etc, a container would in
> fact be an RI.

ok, now you say it too, cool :-)

> analogy: we have the servlet spec, a servlet RI should provide a way to
> run any app conforming to the servlet spec.
> 
> 
>>3. component directory
>>This is a list of components that work with Avalon containers. This is 
>>basically Apps + Excalibur + all components in Commons that we export from 
>>Excalibur with MicroContainer. The actual components are *not* stored here 
>>unless they are wrappers for non-avalon components (like some of the 
>>current Apps). It is basically a list of "this is the stuff you can put in 
>>your container.
> 
> I like, partially. Separation between reusable components on micro level
> (threadutils) and macro level (hsql) is nice.

Reusable components in Commons instead of Avalon is what I like best of 
this.

>>4. site
>>5. sandbox
>>
>>The 4 and 5 is basically just for developers.
> 
> hmm. "site" would contain docs, which target users too. Feel I miss the
> point?
> 
> 
>>So a newbie user comes in and 
>>sees this:
>>
>>1. Get the framework.
>>2. Check the list of containers (all 3 of them). Pick one that suits your 
>>needs.
>>3. Pick all the stuff you want to put in your container.
>>4. Good to go!
> 
> 
> I like this one:
> 
> 1. get development kit (with kitchen sink and microwave)
> 2. go!
> 3. read some docs
> 4. add own stuff
> 5. remove example stuff
> 6. go!
> 7. read more docs
> 8. modify own stuff
> 9. go!
> 10. run distribution "wizard"
> 11. go!
> 
> as the approach for newbies.

:-)

>>Like Pete, I'd prefer just one container. But given the different 
>>requirements for containers I don't think "one single container" will work. 
>>I do think that all containers will be able to run all components, but the 
>>way they are managed and the grade of committment to Avalon architecture 
>>differs - and I do not see how that can be avoided.
> 
> +1

+1  Once they said that users needed only on Java... ;-)

>>Maybe we can provide some three-point checklist for the containers.
> 
> +1, put in a disclaimer ("this is informative and not completely correct
> or agreed upon", or whatever) and put it in xdoc, I say.
> 
>>Maybe even a checklist. Check all checkboxes, click on submit, and we'll 
>>tell you what container you want. :)
> 
> +1
> 
> 
>>Other points:
>>  + Logkit out of Avalon and to top-level or Commons.
> 
> will never happen =(
> politics.

I disagree ;-)
Never say never ;-)

>>  + Testlet DIE DIE DIE kill it already for the love of God.
> 
> I'd say propose a vote

+1

>>  + Excalibur/Event (SEDA/SILK) to Framework or sandbox.
> 
> sandbox

+1

>>  + Excalibur/Command (SEDA/SILK???) to Framework or sandbox.
> 
> sandbox

+1

>>  + AltRMI to top-level within Jakarta
> 
> not ready, so sandbox

+1

>>  + Rest of Excalibur minus Fortress and MicroContainer to Jakarta-Commons.
> 
> have reservations.

Let's decide package per package, as we are doing now.

>>  + Concurrent to Commons (already done?) or ditch in favour of 
>>util.concurrent: 
>>http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
> 
> 
> ?
> 
> why mix this up into the discussion? What is (yep, being lazy)

0 Kelvin (doh)

>>In short, I want Avalon to be: Framework + Three Containers + Component 
>>Directory
>>
>>And nothing more.
> 
> 
> hmm.
> 
> I want Avalon to be: Specification + Implementation + Component
> Directory + Development Kit + Nurturing place for avalon-based stuff.

Whic means that you agree, since the sandbox is implicitly needed and 
Dev kits are implicitly needed for each container :-)


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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