> 3. A cache server/connection pool - don't agree
>
> I don't see 3 as working because they can/should be built on generic
> pooling caching classes. The current Avalon connection pool inherits from
> AbstractThreadSafePool (or something similar). Now to make that pool
> independent of Avalon would require duplicating the code in the Pool
> framework.
It doesn't have to inherit from AbstractThreadSafePool - it can use it.
And with a simple adapter you may be able to plug different
ThreadSafePools ( tomcat has a mini-pool, and I bet other
projects have the same - having them as clearly separated
components would eventually lead to merging between them ). Same for
ThreadPools, etc.
You don't have to duplicate code - just to reorganize the code around
basic functionality and start using abstractions beteween components.
> This is not uncommon - if you look around you will see even more pervasive
> generic pooling/caching framework (minerva is a good example). Now by
> forcing each component to be self contained then you force duplication of
> code.
I disagree with this.
"Self contained" doesn't mean it can't use other components - it's just
that the other component is used via in interface or mechanism that allows
you to replace it.
> >Does it take more work to build and maintain these services in a modular
> >fashion? Well, it takes a *little* more work up front,
>
> I think you underestimate how much work it is. I have been working on a
> generic framework who's charter is just that - and I have found it painful
> to do. Worse it takes a lot of time.
Maybe that's the problem - the "generic framework". It seems people need
"generic components" they can use, not frameworks. CPAN is not a
framework, is a collection of components.
--
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
