> 1. Why do I use Avalon? To develop enterprise level applications hoping to gain reusability, improved configurability and structural stability in the developed components.
> 2. What do I feel Avalon's mission to be? In our opinion Avalon should concentrate on creating/maintaining a flexible component API (already done), a container that supports this API and a set of components that comply with this API. Development should not be split between several container implementations that do the same thing in different ways. Instead one "official" container should be developed that supports the component API and which can run all the components (Excalibur et al.). One important thing is that the container and the components published by the Avalon project should fit together and be well documented to reduce the time to learn the system. After achieving the goal to have one "official Avalon Container", developement effort should go into adding to the component API, Container features and components for standard operations. > 3. Where do I see Avalon by the end of 2004? We'll leave that to the developers of Avalon. > 4. How do I feel about Avalon as an umbrella project vs. a single > product? We strongly feel that only one product should be created by the Avalon project or development would be split too much between the different projects. The result would be a number of poorly documented, half-finished container implementations whose components can't be easyly interchanged. New comers would complain about lack of guidance as every maintainer would favor his/her own creation. Avalon should create one container and maintain that. Everyone would be free to implement his/her own container but NOT as part of the Avalon project. > 5. Should there be a formal framework specification? As Avalon would only maintain one container, such a test suite is not necessary. It would help only in the creation of many containers which would split users and developers alike into different small, competing groups. Futhermore it would waste a lot time that could be spent on standard components, container improvements, bugfixing etc. > 6. If so, what should it consist of? No answer because answer to 5. is a big NO. Kind regards, Jan Schroeter, Ole Bulbuk ___________________________ Ernst Basler + Partner GmbH Tuchmacherstraße 47 DE-14482 Potsdam http://www.ebp.de --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
