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 intuitive. > >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! :-) Fede
