I agree with what your saying about the pool stuff (examples I used were from excalibur pool, not mpool). Presumably mpool pools still need some level of parameterization which that I need to address within the component meta-data (i.e. Merlin directives for pool creation).
I don't agreed with the "deployment" == "lifestyle" assumption - but more on that in line.
Berin Loritsch wrote:
Stephen McConnell wrote:
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 terminology that I understand ...
* "lifestyle" is a set of policies controlling component creation and destruction
* "factory" an object used by a lifestyle implementation to handle new component deployment and decommissioning
* "handler" an implementation of a particular set of lifestyle policies
* "deployment" - the act of taking a component though its "lifecycle" to an established state
* "decommissioning" the action of taking a component from an established state to an un-deployed state
* "lifecycle" is a collection or ordered stages
* "stage" a step in deployment lifecycle that may implemented using a specific strategy
At the end of the day I think we are in sync. When you using the term lifestyle you thinking "a type of lifestyle handler"- and I'm thinking "a set of lifestyle policies".
The second hole I'd like to bring up has to do with sizing the pools.
<snip-pool-related-stuff-I-agree-with>
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.
Its not bad as that. If you want you component to be pooled you do:
@avalon.component lifestyle="pooled"
I.e. no change. Howver, in the mpool and pool packages there are supplimentary marker interfaces (Recyclable, Reclaimable, etc.). This is simply meta-info about the component type and should be expressed in the meta-info package - not in marker interfaces.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
