avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Util
Date Sun, 25 Feb 2001 02:56:03 GMT
At 06:42  24/2/01 -0800, Federico Barbieri wrote:
>> >The same apply to camelot.
>> could expand on that ?
>part of camelot is what I've renamed avalon.container as it's a general
>purpose set of patterns for container, contained, etc. while part is
>much more linked to the specific kernel implementation. 
>As example Container, Deployer are general purpose and should go into

oh okay - there is Avalon related container components and the generic
container components. I was thinking of eventually sub-packaging em (ie
camelot.avalon.* but as camelot is not widely used yet I thought it was a
little premature. Also considering the recent refactoring burned away a lot
of the Avalon specific files (there is only 4 left that I can see) I am not
sure an extra package for 4 classes is worth it.

>Separation is kinda difficult... I was thinking: avalon.configuration,
>avalon.context, avalon.component are all decoupled one from the other.

I don't mind that (actually I advocated that ages ago) but I also remember
Stefano convinced me this was bad ... though I can't remember the reason.
It should be in the archives ;)

>So should be avlaon.container. 
>avalon.camelot should contain higher level classed that uses all the
>avove packages to be more usable.

perhaps - but as it stands camelot interfaces only use a small proportion
of it but the implementations are themselves built on top of the other
bits. I think we need more justification to split camelot at this stage.

>I'll upload the proposal later today. 

kewl - could it be in proposal/4.0 or proposal/red or something similar ;)

>> >I'd like to move out of the util all avalon related classes and find
>> >them a place in avalon.* like avalon.log avalon.thread etc.
>> certainly possible - though we would end up leaving heaps of deprecated
>> methods around in util that may make it look a little less than clean ;)
>That's the idea... that's a 4.0 proposal! No back compatibility. :-) I
>know I'm going to be flamed but... IMHO cleaning 3.1a is wrong... it's
>going to need thousand of deprecation and we'll never reach a final

Perhaps but I want to finish 3 to make it usable and largely stable. I am
building stuff on top of it at the moment. Theres a few things currently
lacking (logging/exception hanlding and management) that I want. After that
I was just going to clean and refactor. 

While working on 4.0 now is alluring I think we should at least finish 3 ;)
(Or at least I will).

Besides I have some big visions for 4.0 (or maybe 5.0) that involve a lot
of stuff Berin was talking about. ie using MOM/JMS and LDAP/directorys to
build distributed and replicateable (is that a word?) server farms. However
that is definetly in the arena of "pipe dream" at the moment ;)

>The evolution will be more or less 3.1a-> 3.1b-> 3.1-> 3.2->4.0
>that is: let's get a final release of what we've got and work on 4.0 in
>parallel. 3.2 includes the deprecation needed to move to 4.0. 
>Sound reasonable?

Don't need to formalize it now. 

>i see three slightly different set of classes

Very similar to the first three levels I described avalon as on my post to
jakarta-general ;)

>thou I don't know if it makes any sense trying to separate them... 
>for the sake of sharing code it makes quite sense to separate the first
>into avalon.util while the other two can coexist in avalon.* Any ideas?

Sounds like my plan ;)



| "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               |

View raw message