Peter Donald wrote:
> On Sat, 5 Jan 2002 03:38, Berin Loritsch wrote:
>
>>By deprecating Poolable and Recyclable, and adding Resettable to Framework,
>> the Pool can take advantage of the Resettable interface itself. In fact,
>>the Resettable interface is more descriptive of what Recyclable does.
>>
>
> -1 on moving Resettable to framework, I would be more inclined to move
> ThreadSafe/SingleThreaded outside of framework than adding anything more in.
:/
When we were in our own isolated world, we could demand that in order for a
Component to be considered a Component, it had to be ThreadSafe. That was
before we had a dose of the real world with Cocoon. There are a number of
Components in Cocoon, all with varying needs for concurrency management.
When a Component is ThreadSafe, then the Component takes on the concurrency
management, and all is well. However, there are Components that are not
ThreadSafe in the real world. Neither can they be--as they have interfaces
that preclude it (A SAXHandler can never be ThreadSafe due to the order of
calling methods).
We added those interfaces to mark the Component's lifestyle. I think this
is an important addition that should remain in Avalon Framework. Lifestyle
is just as important as lifecycle management.
Adding Resettable to framework will offset a hole where Components must have
a certain state reset after one use.
I would be -1 removing the ThreadSafe/SingleThreaded interfaces, and Resttable
does belong with them.
>>The overall changes I am proposing would either add Resettable to
>>org.apache.avalon.framework.thread or move those interfaces and Resettable
>>into org.apache.avalon.framework.lifestyle. It would also deprecate
>>Poolable and Recyclable, and lastly make Pools work with Objects rather
>>than Poolables.
>>
>>The last change is not backwards compatible, and the same arguments can be
>>made for its change as the change to PriorityQueue.
>>
>
> -1 on backwards incompatible changes. Just create a whole new component and
> deprecate all of the old stuff if you must.
>
> For instance I actually have a component in excalibur.xpool that pools
> resources other than components (No need to implement Poolable or any of the
> stuff). This is mainly so I could pool things like datagrams, Chunks
> (basically reusable byte arrays) and other similar objects.
>
> I would prefer you went this path and created a new package for your new
> components.
Yes, but it does beg what the package name should be.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
