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

/LS


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