Stephen McConnell wrote: > > Following the initial discussions on the pmc concerning > avalon direction, roadmap, etc. I wanted to post my thoughts > about Avalon and the direction over the next year. > > 1. Development Consolidation > ---------------------------- > > One api, one reference implementation. +1, but please a simple to use one!
> Rather than launch > into a A5 scenario, I am in favor of moving forward by > building and evolving on A4 +10 > - no radical change - but some significant and important > changes in the terms of depth. Yes. > > 1.1 Starting with Avalon Framework 4.2 > -------------------------------------- > > More and more I'm seeing the need for different levels of > APIs. We have the A4 framework contract for classic > container/component interaction - but room for evolution with > respect to constructor management. I see this as an avalon > framework 4.2 release. > Yes. <SNIP 1.2 which I don't understand :) /> > > 1.3 Reference implementation > ---------------------------- > > Probably the most important thing that will need to happen in > the coming months is the elimination of different development > directions. One component architecture - one development > community - one roadmap. This involves the establishment of > one and only one reference implementation > - termination of divergent streams, and the focus by the > community of the evolution of the reference implementation. Sounds good, but as I wrote previously, the whole Avalon community has to agree on which road to take and not only "the one doing the work". <SNIP 2 where I don't have an opinion yet/> > > 3. Avalon Component Library > --------------------------- > Yes, please, a component library! > There are a number of aspects to address with respect to an > Avalon Library. > > 3.1 Compliance with Avalon-Meta and block packaging specs. > ---------------------------------------------------------- > > A most important factor is the requirement for single > component model compliance. Usage of standard meta-info > across the board, standard packaging of composite components, > and a very complete and consistent approach to the definition > of remotely deployable units. In other words > - making sure that the component library is very easy to use > and very simple to leverage. > And make sure that the components run out-of the box in the most recent containers including at least Fortress (ECM would be good as well, but perhaps we can forget that one) <SNIP 3.2 and 3.3 - this should be discusses separately/> In general, discussing these things is a very good thing! Now, I think focusing on 4.2 as Stephen suggests is a very good idea. In general, the next step could be to discuss several aspects separately. One major aspect/concern is currently imho logging (and I will stress this point until I see a solution). There are too many subprojects with circular dependencies and a clear vision there is absolutely missing. If noone else has a vision and will start a discusion about it, I will do it in the next days. So, keep on! Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
