avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Website docs
Date Sun, 31 Mar 2002 12:31:06 GMT
Peter,

All points noted.  Will implement.

-PH

>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.
>




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message