> > What's wrong with having multiple thread pools or db pools, each
> > having special characteristics and working best in different situations ?
> 
> That it requires a special effort to find out which one fits your project
> best. The classical problems of reuse multiply: it's not only fetch a library
> and find out how it works, but fetch many libraries and find out how every one
> work -- then research their strengths and weaknesses and choose the one that
> suits you best. Now you can safely say that it seems less hassle just to write
> your own.

Ok, let me rephrase it - right now we have no library, only projects with
some usefull code inside - but you can either take the whole project or
cut&paste the code.

We have the duplication already - organizing the code so that the
"connection pools" will be in the same category, next to each other is a
big step forward. 

Another big step forward will be in 6 months, when either the 2-3 will
merge, disapear or find a specialized niche. 

I don't see any other way this could work - Darwin needs time, and no
other good selection method is available. Removing the "protection" of the
project will allow the evolution of the utils.

> If there must be different libraries doing the same things, it must be real
> easy to choose the right one -- via documentation, benchmarks...

For start it'll be really easy - each project will keep using the one it
used before. And in 6 months we'll know which library is the good one -
Darwin will tell us. 

The alternative is to debate for the next 6 months about which
DBPool is the best and why. And we may reach the wrong conclusion.

-- 
Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to