Niclas Hedhman wrote:
On Friday 17 October 2003 07:19, Stephen McConnell wrote:
Declaration of a pool deployment --------------------------------
<component name="thing" type="Whatever"> <pool type="ResourceLimitingPool"> <minimum>10</minimum> <maximum>10</maximum> <increment>10</increment> </pool> </component>
And if the component lifestyle is not pooled, then the pool directives would be ignored and an appropriate warning would be generated.
Implications ------------
1. update avalon-meta @avalon.component tag to include collection and
distruction policies
2. update Type definition to expose respective policies
3. update avalon-composistion to include pool meta-data
4. update avalon-composistion meta model to recognize pool meta-data
5. update avalon-activation to support pooled service provider resolution
Why not worry about this at the same breath of "pluggable lifestyles", and that each lifestyle is provided an optional "fail-safe" (probably namespace aware) configuration section per component?
Are we not at a juncture where it would make sense to start thinking of that, together with pluggable life cycles?
Plugable lifecycle - no problem - but plugable lifestyle? I not convinced (yet) that there is a case for this (but read on). I'm open to scenarios that show that my assumption is incorrect - but in the meantime I have the possibility to nail down the semantics of the assumptions we currently have. However, lets assume that there are additional lifestyle strategies. In such a case would could have:
@avalon.component name="fred" @avalon.lifestyle type="MyCustomLifestyleInterface"
The type argument "MyCustomLifestyleInterface" is simply a deployment dependency. The container resolves the dependency and provides the handler for the lifestyle to the lifecycle handler. The lifestyle handler takes into account the "collection" and "destruction" policies declared by the component and accessible via the meta-info model.
Using this appraoch I'm keeping things focussed on resolving semantic questions on the current "standard" suite, but I'm maintaining the potential for pluggable solutions (even though in this particular context I'm not convinced we need this). But keep in mind that a lifecycle handler aggregates a lifestyle handler and as such, if you have a plugable lifecycle, the custom lifecycle can provide alternative lifestyles.
Stephen.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
