avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Date Wed, 26 Jun 2002 15:17:08 GMT

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> Sent: den 26 juni 2002 16:02
> To: 'Leo Sutic'; 'Avalon Developers List'
> Subject: RE: Fresh Outlook: (was RE: [desperate plea] RE: The 
> need for 'hints')
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > 
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > Nicola, your problem is in your loose definition of 
> component. Not 
> > > all objects are components.  The SocketManager is a 
> component. The 
> > > Socket is an object.
> > > 
> > > *ALL* components have the following attributes:
> > > 
> > > 1) Separate interface from implementation (Socket fails here)
> > > 
> > > 2) No argument public constructor
> > > 
> > > 3) Distributed in binary form (aka jar file)
> > 
> > So if I come up with a general Socket interface, we're good 
> to go with 
> > Socket as component?
> > 
> > Didn't think so.
> > 
> > Berin, you can argue endlessly that a socket isn't a
> > component, or what makes a component. Point is this:
> > 
> >  + There will always be something that fulfills your every
> >    requirement for a component but that must still be pooled.
> Leo, Who said this was about pooling?  This is not about pooling.

There is a connection, but I should have spelled it out:

 + Because the architecture you advocate implies no transparent pooling
   done by the container. (Everything you look up is thread safe.)

 + Because this issue is always linked to the use case when we have
   components that should be pooled.

(Unclear, I realize.)
> The concept of representing your information as 
> psuedo-components (I refuse to give them the honor of full 
> component status) does not scale because you are forced into 
> one way of doing things, and you are requiring the container 
> to make up for your lack of design.  Those things are bad.

Berin, your explanation for why it does not scale is a
non-explanation. It does not scale because

 + I'm forced into one way of doing things

 + I'm requiring the container to make up for my lack of design


Either of these two, with actually only the first being even
remotely similar to an explanation, does not explain why
it won't scale.

*The only time one way of doing things is the wrong way is
when that way _in itself_ does not scale.* So you can not say
that because I do things one way, it won't scale. You have to
say "Because that way means you can not do this this and this."

So, to distill it to basics: Why will it not scale, if I let
Sockets be Components?

> What happens if you want to change the persistence mechanism? 
> What happens if you want to change the way security is enforced?

I see security policies as something entirely orthogonal to whether 
or not a Socket is a component (which is the practical case we started 


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

View raw message