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).
Not really--which is the beauty of it.
I don't agreed with the "deployment" == "lifestyle" assumption - but more on that in line.
I'm the one who created the definition for the word, as I am the one who first used it in Avalon contexts. How can it not be what I defined it to be? Help me understand how that could work.
Berin Loritsch wrote:
The terminology that I understand ...
* "lifestyle" is a set of policies controlling component creation and destruction
Hmmm. Lifestyle == deployment strategy. You understand incorrectly.
* "factory" an object used by a lifestyle implementation to handle new component deployment and decommissioning
Same as the Factory pattern.
* "handler" an implementation of a particular set of lifestyle policies
Correct
* "deployment" - the act of taking a component though its "lifecycle" to an established state
Ok, but that does not address the issue of *strategy*.
* "decommissioning" the action of taking a component from an established state to an un-deployed state
Ok.
* "lifecycle" is a collection or ordered stages
correct.
* "stage" a step in deployment lifecycle that may implemented using a specific strategy
Just drop the phrase "that may implemented using a specific strategy" and you've got it. THe extra phrase does not add anything relevant to the definition and it is bad grammer. ("that may BE").
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".
I believe I have already stated what I meant when I coined the term.
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.
Not quite. The interfaces Resettable and Recycleable are *functional*. They do not merely mark the object. They provide a point for the object to reset itself to an initial state when we are done with it. Now, I agree that the interface Poolable is meta information, which is why the MPool stuff does not have an equivalent to that.
--
"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]
