Hi Phil, thanks a lot for feedbacks and for mentoring, much more than appreciated. I take advantage to wish you all a Merry Christmas, all the best, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Dec 24, 2010 at 4:32 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > On Thu, Dec 23, 2010 at 2:28 AM, Simone Tripodi > <simone.trip...@gmail.com>wrote: > >> Hi Phil, >> >> >> >> >> org.apache.commons.pool2.impl >> >> |---- generic >> >> |---- reference >> >> |---- stack >> >> >> >> common stuff could be included directly under impl. >> >> >> > >> > What exactly would that be? >> > >> >> just realized that there are no common stuff shared by different kind of >> pool :P >> >> > >> > I was going to propose dropping the stack pools altogether. The >> LIFO/FIFO >> > config option in the generic pools makes them mostly irrelevant (i.e., >> you >> > can get the same behavior with a suitably configured GOP / GKOP with much >> > more configurability) >> > >> >> I had the same feelings here, but felt a little shy on saying that. >> > > No reason for that :) > > >> You've my full support on this, I agree on dropping stack based pool >> implementations. >> >> Good. Lets do it. > > >> > I don't want to sound too conservative and I will certainly not stand in >> the >> > way of new / different pool implementations, but I would personally >> prefer >> > to keep the number of included pool impls as small as possible. >> > >> >> I propose a more democratic way, I mean, like you made us notice, >> keeping/adding the pool impl only if it makes sense to. >> I wouldn't think about the included pools in therms of "size" but >> rather in therms of "meaning" >> > > Agree this is completely up to the community and them who bring the > patches. The reason that I tend to be conservative is that more impls mean > more bugs, which makes fixing them all and getting releases out quickly > harder. Pooling code is tricky to maintain, so fewer pools with > less-exotic features might be better all around - not just in terms of > maintenance, but also approachability from the standpoint of users and > contributors. > >> >> > I think the first thing we need to do is to decide what implementations >> we >> > are going to a) keep or b) add for 2.0. I have been convinced that we >> need >> > to keep GKOP as well as GOP. As I said above, I would like to consider >> > dropping the stack-based pools. I think we should keep the >> reference-based >> > pool and I am open to the new ones you suggest, just don't have use cases >> > myself for them. >> >> I'm not ready to show use cases too, sorry :( But they can be added >> with a trivial refactory, moving the current SoftReferenceObjectPool >> implementation to an >> >> AbstractReferenceObjectPool<T, R extends Reference<T>> extends >> BaseObjectPool<T> implements ObjectPool<T> >> >> then in subclasses do the minimum. I can quickly provide a patch for it. >> > > I am OK with this as long as it does not complicate the code too much. > >> >> > There are quite a few impls buried in PoolUtils that might >> > make sense to pull out (or eliminate). >> > >> >> I just made a census (with proposals): >> >> * PoolableObjectFactoryAdaptor >> * KeyedPoolableObjectFactoryAdaptor >> * ObjectPoolAdaptor >> * KeyedObjectPoolAdaptor >> >> I propose to eliminate these adaptors, > > > That's the spirit - he he > > >> they implement a behavior that >> users can replicate with a trivial code and without build a >> pool/factory on top of an existing ones >> >> * CheckedObjectPool >> * CheckedKeyedObjectPool >> >> These can be eliminated too, having introduced the generics >> > > +1 - I think Gary may have mentioned this already. Lets get rid of them. > >> >> * ObjectPoolMinIdleTimerTask >> * KeyedObjectPoolMinIdleTimerTask >> >> I propose these pools can be pulled out and moved to a proper package >> >> I wonder if anyone uses these? I wonder also if it might be better to just > expose ensureMinIdle. > > >> * SynchronizedObjectPool >> * SynchronizedKeyedObjectPool >> * SynchronizedPoolableObjectFactory >> * SynchronizedKeyedPoolableObjectFactory >> >> These could be pulled out too, even if something suggests me that >> pools synchronization can be realized with just a Proxy, I'll do a >> little experiment to submit so you can evaluate. >> > > Interested in ideas on this. Here again, I am not sure how much use these > actually get. > >> >> > What might make sense is to replace "impl" with "instance" (or "object") >> and >> > "reference" (or "ref"). So you have o.a.c.p, o.a.c.p.instance, >> > o.a.c.p.reference. >> > >> >> sounds much better than keeping the intermediate "impl", I agree :) >> >> Should I have to write all these notes on the wiki and open issues >> before proceeding? >> > > I would say wait a bit to see if anyone has problems with above and if not, > go ahead and make the changes. > > >> Many thanks in advance, have a nice day! >> > > Thank you! > > Phil > >> Simo >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
