> 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.
+ We do not want to write a separate manager for each one of
those. No matter how much that fits your view of good
architecture. *It is not practical.*
Can you convince us that you have a better solution than
what exists now, or that we for some reason do not want the
container to handle the pooling, do so.
The arguments we have had regarding that would indicate
that no such solution exists.
As for the reason one would not want to implement pooling that way,
I have repeatedly asked for a justification of the claims that
"it does not scale" etc.:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102335077401400&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102335398303810&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102335214102411&w=2
but the absence of an answer indicates that no such reason exists
either.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
