avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Federico Barbieri <scoo...@betaversion.org>
Subject Re: Util
Date Sun, 25 Feb 2001 11:09:03 GMT
Peter Donald wrote:

> >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 ;)

don't know but now if you look at the package you can easily see the
different design patterns decupled in their folder... it's more

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

Need to work more on that... camelot is a bad beast! :-)

> >I'll upload the proposal later today.
> kewl - could it be in proposal/4.0 or proposal/red or something similar ;)

done. There is a changes.txt. More work is needed thou.

> >> >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
> >release.
> 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).

Tha't exactly what I'm saying... we can't go for a 4.0 without a 3.1
final release. That whould be a very bad development choice. On the
other side we can make 4.0 clean and nice!

> 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 ;)

Keep it worm... if we set up things the right way 4.0 generation will
really kick asses! :-)

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

just to keep in mind and work trasparently in public... 

> >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 ;)

not everybody reads jakarta... it must be posted here too! :-)

> >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 ;)
> Cheers,
> Pete

Ok so let's dig out the 4.0 proposal! I'd like to have everybody's
opinion since that is supposed to be VERY VERY stable! :-)


View raw message