Just a note to say that I'm working though a semantic crisis. That means that you have to read the entire email before replying because I'm starting with X, proposing Y, and ending up with a set of recommendations for X+.
I read the whole RT, and wrapped my head around what you are saying. Let me shoot a couple holes in what you proposed with some practicalities. First, I am the one who coined the term "Lifestyle" because I couldn't find an adequate term at the time to describe what I was getting at. In essence, lifestyle == deployment strategy. They are one and the same. That is why poolable is a lifestyle, like singleton and thread-bound componetns. Those are all deployment strategies.
The second hole I'd like to bring up has to do with sizing the pools. THe old Excalibur Pool package is Ok. I know Leif did a lot of work to make the ResourceLimitingPool rock as much as possible. The major issues here are that we cannot really anticipate the proper pool sizes for the components. One of the things that the Cocoon project quickly found out was that they had to come up with some rough ratios for the component pool sizes so that when an administrator tuned the pool sizes for the proper balance of performance and resource usage, it was a conceivable thing to accomplish. It can be a very frustrating thing to balance out those issues. THat is why MPool doesn't require you to specify those sizes. It provides a framework that could be much smarter so that we can intelligently manage the size of the pools.
Requiring the assembler to anticipate the pool sizes is a big mistake IMO. Esp. if they cannot anticipate the environment the system will be run on. For example, if you have a road infrastructure that can handle compact cars, you will overload that infrastructure if you put a bunch of dump trucks on it. You can also run into potential scalability issues as well. It is best not to force someone to be omniscient.
The last thing I am going to say is that the end proposal seems overly complicated. Let's see here. I want to get this component pooled. What is the exact combination of options I need here? Or Let's see here. I want to implement a container. Now what exact combinations would specify pooling, thread boung components, etc.? It hurts my brain thinking about it.
Let's Keep It Simple, Stupid (KISS). I'm just not smart enough to be able to tell someone what to expect when I see a bunch of options like that. It's a question of what is easy to explain. A short list, extensible or not, is much easier than a matrix.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
