Hi, Looks nicer.
On Sun, 31 Mar 2002 02:17, Paul Hammant wrote: > Page http://jakarta.apache.org/avalon/framework/index.html > ------------------------------------------------------------- > > 1) "Target Audience" > > Is now : This documentation is aimed towards developers who are > interested in the design principles of Avalon, or wish to develop code > that will be incorporated into Avalon > > Should be : This documentation is aimed towards developers who are > interested in the design principles of Avalon, or wish to develop code > that will be incorporated into Avalon, or reuse Avalon concepts in their > own application. Okay - also delete the second paragraph in introduction as it is no longer relevent. > 2) "Theoretical Aspects of Component Development" > > I'd like to add a new pattern that we already informally treat > reverently. It is "Interface/Impl seperation". People understand it but > do not really apply it, of it is mucked up. Catalina, for example, is > supposed to be interface/impl separated but is (or was last time I was > active in their mail list) not. The other thing that wven we are > historically a bit guilty of is the separation in terms of jars. We > desire this because we want to hide implementation. Following of from > Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only > see the Client API (CAPI), the Kernel (K) may have chosen to hide the > impl of the CAPI in a different clas loader, not just by dyanmic proxy. > The K/CAPI/HC trinity will be repeated many times over in the most > complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would > be good if we could really start promoting this. At least I am getting > sick of explaining it to the people I meet on the net when they have > something that is almost a good candidate for an example for EOB. One > case wherewe have it wrong is I think cornerstone.jar, it contains > interface and impl and will probably be left as is for historical reasons. I think we should just start discussing about separation of implementation and the interface/contract. Dont worry about describing classloader/jar issues just yet. The main reason I do it is because; 1. it forces you to decouple different modules/components/objects 2. if specified correctly allows you to easily change the implementation of the interface/contract in the future. 3. makes it possible for a user to read documentation about interface without having the implementation details clutter up their perception if you are building objects with the aim of reuse then [2] is important but most people don't build for reuse (and most XP advocates say you should just plan to use not reuse) and thus [1] and [2] are more important. If you feel like documenting that and expanding this then feel free to. Tackling the separation of ClassLoaders/jars is a related but different issue. It could be documented but I think it may be best to tackle this second and put it in a a different document. This is mainly because many applications do not require that level of separation. -- Cheers, Pete "Well you can put lipstick on a hog and call it 'Monique', but it's still a pig." -- Texas Gov. Ann Richards -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
