avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [vote] Excalibur CVS
Date Sat, 21 Apr 2001 01:59:13 GMT
At 10:45  20/4/01 +0200, Leo Simons wrote:
>> >1) a well-documented specification (interfaces; contracts)
>> >2) a (reference) implementation that does nothing more
>> >than implement that specification
>>
>> what specification? We don't have one.
>
>Exactly! ;) (<-- meaning: we probably do need one)

heres where I have issue - we should not have one - we should have N (where
N is some number greater than 1). Because we have N different uses ;)

>> Your model only works if we consider Avalon as just an application server.
>> As soon as this assumption breakes the model falls down. I don't make that
>> assumption (and I would argue against it) so ...
>
>? Why? (really, why? I fail to see it...)
>The model I'm talking about is mostly quite similar to
>what is done with java.* and javax.*, at least with newer code
>like JMX or Connector.

No - there is a number of models in the java std/ext libs. One of them is
the definition of client interface and some utility classes *ie servlet
spec). Other approaches include;

(1) Service + Service Provider Interface. For instance JNDI has interfaces
that that the client interacts with, interfaces/classes the service
provider interacts and a set of SPI implementations (see
File/NFS/DNS/whatever JNDI implementations). 

(2) Framework based spec. See swing it is prime example of this.

(3) Globbing classes with similar content together (ie lets chuck all io
stuff into java.io.*)

(4) Traditional client interface+impl as separate (see servlet spec)

We use each where appropriate. For instance throughout cornerstone we use
(1), (3) and (4) (Hopefully with more (1) in future). We use (2) with
Framework stuff etc.

I think the definition you make between interface/implementation is
artifical for a number of reasons. First reason is that the existing
*frameworks* in the JDK do not make this distinction. Swing (in particular)
and Collections both have imple and intf side-by-side. Separating them out
is not useful for our users. They can still reimplement the things from
scratch (C2s version of CM) but why should they have to for default
implementations?

ie What makes the swing model (which is also a framework) not applicable to
our framework?

>  If we do this, org.apache.excalibur needs to be in the Avalon
>  in the Avalon package. If we want to move parts of Cornerstone
>  to excalibur, it makes sense to instead clean up cornerstone
>  and then rename it to excalibur.

I am confused by this. Cornerstone is one of the things I am happy with and
I really don't want to start moving bits of it to excalibur ... ;)

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


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


Mime
View raw message