> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> 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:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
