At 01:32 10/5/01 +1000, Conor MacNeill wrote: >> From: Peter Donald [mailto:[EMAIL PROTECTED] >> >> Right - and docs will be done by the time we get to implementing this and >> you know this ... so whats your point? > >You have kicked us into design phase and you are proposing a vote on the >adoption of the Avalon framework. Therefore I want to read the >documentation. This is not available and the documentation that is on the >web is in fact misleading. How could I vote +1 under these circumstance.
good point - in that case I withdraw the vote till a bit later then. >> But as you know that and I have said that a few times ... >> somethings amiss??? > >Besides your manners? No. well I am sorry if you are offended. But you asked the same question multiple times and I kind of get the feeling you are ignoring my responses - this notion may have come through in mail - soz ;) >> Compression is not an feature of the framework but of the code that uses >> it. No framework stops you shooting your foot - some make it harder > >Frameworks are the reason the code that uses the framework is compressed. It >is an inherent feature of frameworks. Only OO frameworks - there are other ones that can have minimla compression (ie component based frameworks) which Avalon tries to be ;) >It has good and bad points. Don't you >agree? Highly compressed code for Ant's core would not make Ant easier to >maintain and extend. agreed. >> >And how have they been tested in Avalon? You just stated above that "Well >> >considering that Framework has been designed around Ant as a use >> case this >> >won't be an issue for us". Considering the usage of Ant, I think it will >> >get a fair amount of testing. Natural open source effect. >> >> I don't understand your point here. > >My point is: You have stated that developing code for Ant would duplicate >Avalong but be "raw and untested", whatever raw means. The clear implication >is that Avalon's code is "tested". I am trying to find out how you have >tested. Where is this code deployed that it has received significant >testing. You are making assertions and I want to see the facts. Okay it is based on code from way back (jserv times) that has gradually been refined. The original developers (Stefano, Pier and Fede) are all fairly smart and know their stuff. You can actually see many of the ideas being reflected in industry based standards. ComponentManager stuff is basically a stripped down version of using JNDI to compose systems (like in EJB or servlet land), Configuration et al has similar parralels and context is fairly universal through component land. About the only things in framework that are not present in numerous other toolkits/frameworks are Initializable/Disposable/Startable/Pausable. There is a few toolkits thah have them - Turbine has a parralel Initializable, a lot of toolkits have Disposable (aka Destroyable) interfaces. As for startable and pausable - I have seen a few examples of Startable but only one other example of Pausable. There is currently a JSR that aims to formalize the activity methods (ie Startable/Pausable/Init/disp..) so hopefully that will see their wide spread adoption. As for whether it is useful in the context of Ant - I think so. I have rewritten Ant 3 times so far, first one was a hacked together version that was uuuugly ;) Second was based on Avalon and was probably the best version so far. Third version was Myrmidon proposal. In those times I only found two to three issues (only one was to do with the framework - the rest were about components). And this one change was something I had been pushing for practically since last august. Thus I think it is useful in our context. >If the framework is not providing the services again - just to be clear - the framework does not provide services/components. It provides schaffolding/framework for design etc. >you require to implement >something, if you are driven to hack around it, the implication I draw from >that is that the framework is perhaps not that mature. You are being driven >to hack around it's limitations. What is the framework providing? framework provides: schaffolding/framework for design The configuration hack was just that a hack - it has since been migrated into framework - thankfully. If we came across a similar situation for Ant2 we would just develope a parrallel version in ant. >BTW, will >you base a release of Ant2 on an unreleased version of Avalon? of course not >> >I have other concerns. When you build code with a framework, it is like >> >building a chair with two legs. It only works when the framework supplies >> >the other two legs. >> >> Then you have been subjected to bad toolkits or at least different >> frameworks. AvalonFramework doesn't do anything at all - by DESIGN. > >So, if it doesn't do anything at all, what exactly does it do? It provides form framework/schaffolding/patterns >> It >> offers a frameowrk to work in or a schaffold for design etc. In technical >> terms it is a level 2 toolkit with minimal content and maximal form.] > >Can you give me a reference for the definition of a level 2 toolkit? Not really - should be able to get it by looking through library or more probably on web. From memory the following levels 0 - does not influence code or data format 1 - forces user to use a particular data form/content 2 - forces user to use a particular code form/content 3 - hosted components and takes away main entry point It is assumed that each levels uses level below it (ie level 2 is also a level 1) however I have found this not to be the case with certain component systems (ie MS COM and Avalon/Framework). >> BTW I can't help but sense you have gone into attack mode. It seems like >> you don't understand Avalon and thus decided easier to attack. > >How can I understand it when it is not adequately documented. Yeah I know, >its on the way. How can you propose a vote on adopting Avalon for Ant in >these circumstances. I guess I didn't think ;) >> The fact >> that all your attacks miss the mark is another indicator that you lack >> knowledge about domain. > >Don't be condescending. I am not attacking. I am trying to understand why we >should use Avalon. All I get is assertions. don't take this the wron way but I assume that you want to agree with the basic design principles that motivate Avalon/Framework (ie components/soc/ioc). If you do accept those then my assertions should naturally follow from looking at javadocs ;) If you don't agree with those design atterns then speak up now. Otherwise I will drop this, put up docs and then recall a vote ;) 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 | *-----------------------------------------------------*
