At 09:03 3/4/01 -0400, Berin Loritsch wrote:
>> Hence I propose that we move the "framework" part of avalon to a stable
>> beta release to match c2s going beta. This means that once we commit to a
>> particular arrangement we will effectively required to support them for a
>> long duration into the future. Given this I think we should do the
>> minimalist thing to the greatest possible degree. If a pattern is not
>> stable and applicable to a sufficiently wide an audience it should not be
>> included in the stable framework.
>
>I agree. Does this include Camelot? I think that has been the most dynamic
>part of Avalon to date.
I don't think it is stable enough yet. I want to separate it out like Fede
wanted but it has not been tested enough yet.
>> The most important of which to stabilize is (1). It is expected that
>> overtime (3) will be upgraded and (2) is minimal. So I propose the
>> following guidelines;
>>
>> * If it is a component we don't stabilize it yet
>
>The datasources are pretty much stabilized. I haven't heard too much on this
>list or Cocoon lately about them.
>
>> * If it is not sufficiently general or only applicable "in theory" then we
>> don't stabilize it yet
>
>Not sure on this point. I get the point you are making, but I want to know
>what you mean by "in theory".
Well - I guess the prime example could either be processor package or the
remaining thread package (ie ThreadContext/ThreadPool/ThreadManager). In
theory the processor package is nice. It is based on looking at existing
designs (ie jboss/tomcat/james/cocoon mainly) but as yet we have not
incorporated it widely enough to see if it really is worthwhile.
Also the same with ThreadContext/ThreadPool/ThreadManager - I have been
using the same interfaces for close to 2 years but it hasn't seen wide
application yet. I suspect that we will in the future require the addition
of something like a ThreadControl to send signals/interupts and other odd
things.
>> * If it is utility code then we only stabilize it if (1) directly uses it
>> or C2 and it's clients will use it.
>
>Lock, Framework Interfaces, Configuration, DataSources, is there anything I
>am missing?
CascadingThrowable/ExceptionUtil is about the only other thing that pops
into mind.
>What about the decision to backport the ComponentManagement classes used in
>Cocoon 2? Is that on hold, or is that going to hurry up now?
I am not sure I fully understand it - I would like to backport it but thats
is up to you ;) If you think it is bonza then we can backport it.
>> Given this I propose that the following 2 hierarchies
>> * org.apache.framework (stable framework code)
>> * org.apache.avalon (unstable/untested code or components)
>
>I thought the whole framework was Avalon?
Well I guess it is a naming thing. It is really hard to "sell" avalon
because it includes everything - including the kitchen sink ;) I want to
separate out the stable from non-stable and I thought this was the best way
to do it. I am really open to anything ... the only limitation is time
because we need to be stable before c2 is.
>> Initially I wanted to separate out implementation and interfaces but given
>> our tight deadline I no longer think that is pertinent for this version.
>
>Are we talking an official version 3.x or version 4.0?
I was thinking we up the framework classes to 4.0...
>> So what do I think should be in org.apache.framework (looking at
>> arrangement in current proposal CVS)
>> * Configuration package
>> * ComponentManager package
>> * Context package
>> * Lifecycle package
>> * Logger package (Contains *Loggable)
>> * part of thread package (namely ThreadSafe/SingleThreaded)
>> * CascadingExceptions and ExceptionUtil
>
>* DataSourceComponents
>
>They are _very_ well tested by a number of Cocooners, and the only bug
>reported has been addressed.
It has been well tested but it is not "framework". It doesn't form part of
components lifecycle or management etc. In fact it could be reimplemented
independent of Avalon/Framework in theory.
For instance a new component just added to commons (namely pool) is IMHO
better than our version of pool. It wasn't until I saw it that I saw our
version was lacking (also when I tried to pool datagram-packets that it is
impossible to implement poolable with). Ideally if that proves to be better
in long run it would be better to allow us to switch in that implementation.
I agree we should stabilize it though (maybe even marking it as stable in
javadocs) however I don't think it should be in same repository as other
lifecycle orientated code.
>> I will update the proposal directory with an outline of what I believe is
>> the right way to do this. Then we can get to voting/opinions/niggles etc.
>> Once we do this we have to develope a strategy to update the current users
>> of avalon to use this new code (and if we start a new CVS for it like
>> jakart-avalon-framework).
>
>Looking forward to seeing it. We are talking about the /proposal heirarchy
>in this discussion right?
Yep - I will probably check it in tomorrow .. SAMBA has crashed and I
currently can't access my code to commit it ;l
>> Anyway thats the basic outline of something we can do. One thing I do have
>> a query about is whether we want to keep the interface "Component" around.
>> Currently "Component" is what is returned from ComponentSelector and
>> ComponentManager which means that any components stored in those objects
>> must implement COmponent. This can be a PITA when you want to store JDK
>> type objects in the CM - I have run afoul of it a number of times and have
>> a number of classes who only exist to implement Component. Hence I would
>> like to make CM and ComponentSelector return Object instead and completely
>> remove the Component interface.
>
>That would make it more consistent with the JavaBean approach. But then I
>have to ask, "Why have a COMPONENT management interface?". The idea was to
>keep the Components conceptually separate from regular classes. Components
>manipulate Classes, either through containment or through some other means.
That was the idea - the question I am really asking I guess is the
conceptual purity worth the impracticality. Some days I would say yes -
other days I say no. In general useage I would say no but for building
other frameworks I would say yes ... so I am not sure ;)
>> Votes/Comments/proposals/etc?
>
>I am totally for Apache Avalon's Framework to be Beta and not changed. I
will
>help in any way I can.
excellent!
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
