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 >avalon.container.
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 >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). 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 ;) 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 | *-----------------------------------------------------*
