I understand your concerns. Could the component "reset" method be called
by an Accessor extension? Absolutely. The Resettable interface applies
to generic objects that the PoolManager manages. As far as the PoolManager
is concerned, it only works with objects. It doesn't care wether the
objects are components or not.
I disagree.
I only mentioned the implementation details of the pool. The MPool code is agnostic to the type of object pooled.
Without any external semantics (i.e. independently of any extension), an implementation of the pooled lifestyle (a pooled lifestyle handler) will receive requests to release objects and cannot make assumptions about the notion of resettable components unless the implementation does not apply decommission/new-instance re-population semantics. I.e. a strict framework spec interpretation of poolable is that an object returned to the pool is an object that must be destroyed and that a new object must be instantiated to repopulate the pool. Any other assumption contradicts the framework spec. An extension does not change this conclusion because a pooled lifestyle handler must function predictably independently of n possible extensions invoked during the release phase.
With all due respect, such a strict interpretation takes away any and all value of pooling the component. It would be quicker and easier to simply generate new component instances on demand. There would be a much lower overhead.
I think a light-weight method to reset an object/component is a valueable concept that should not be thrown out. It is already in use with ECM based code (i.e. Recyclable.recycle), so we have existing users who truly appreciate this feature.
There is a demonstratable overhead to the initialization process of Avalon components. Perhaps it is the interpreted configurations to blame. Perhaps there are other factors. Nevertheless, in many cases it is less costly to clear out some interim state variables than it is to kill an instance and reinstantiate it.
I agree that Resettable as Accessor extension appears on the surface to makes sense - however, if you look at the separation of responsibilities, you end up with a contradiction between the framework spec and pooled
object implementations.
I.e.
(a) pooled objects in framework are broken, or (b) pooled objects cannot be container independent, or (c) a common container side pooled object model is required
I understand that. In the past, attempts to add a "Resettable" interface to Framework have not passed. That would make it part of the overall contract.
Lets make a mind jump for a moment. Assume that pooled objects are *not* part of the framework. In fact - lets go a step further and make the conclusion that *pooled* is an implementation level abstraction that exists between a family of components - and that the implementation semantics require exposure of policy across a service interface (thereby establishing
the implementation detail awareness ... a.k.a. family implementation policy).
Before I can make a mind jump, I need a translation. What are you saying here? I got lost after assuming that pooled objects are *not* part of the framework. Officially, they are not--although they are provided for with the release() semantics.
If you take this mind-jump and accept the ramifications ... you end-up making the conclusion that there is a particular abstraction in the container/component contract where pooled objects do not exist - and instead - we recognize at least two levels:
(a) a consumption abstraction layer (b) an implementation aware abstraction layer
Hmmm. I'm still lost here.
In practical terms this suggests that there is an framework API that deals with pure consumption oriented components (service oriented). Extending this layer is a potential for a pooled object aware framework (i.e. a layer that assumes release semantics).
There is a slight glimmer of light now...
You are referring to the ServiceManager.release() family of methods. I think I need something more concrete to wrap my head around it though.
How to resolve this? IMO the key point is to recognize that there is a service dependency assumption that can be declared by a consumer that reflect awareness of pooled semantics. A component declaring awareness of pool semantics under a dependency declaration can be handles differently to a component that does not.
Ok. I think I'm with you here....
For example:
@avalon.dependency type="Widget" pool-aware="true"
I.e. the declaration by a consumer that a component implementation acting in the role of consumer is pool-aware (as distinct from a default policy of non-pool-aware). This sort of information has practically zero value at runtime, by it can be used at assembly time be assuring that a correlation between pooled component providers and pool-aware consumers is rationalizable and predictable.
You lost me here again. I think what I really need is something that demonstrates the real problem in hard code before I can make the leap you are referring to. For example, proxying component implementations has a demonstratable value for protecting the state of the component. I can furnish examples in code to show the increased security/reliability of using component proxies.
I think that is what I am missing here. Up to now, it seems like a lot of mental excersize for little or no perceived value. We're still looking at the problem space from two different angles--and from where I am sitting, I can't see the problem you are seeing.
Conclusion ...
Help me understand the problem, and I may agree with the conclusion. For now, I have no basis to make an intelligent decision one way or the other.
--
"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]
