On Thu, 10 Jan 2002 01:58, Berin Loritsch wrote: > Peter Donald wrote: > > On Wed, 9 Jan 2002 03:12, Berin Loritsch wrote: > >>I think we have come to the conclusion that Poolable interface is not > >>helpful, and makes certain things more difficult. The remainder of the > >>discussion has been what *else* people have found limiting. If Avalon > >>is not to be moved into absolescence, it must learn from its limitations. > >>Periodically we need to discuss what works and what does not work. > > > > Agreed - lets throw out ComponentSelector and possibly Component > > interface > > > > /me runs and ducks for cover ;) > > Wow, I actually thought you were going to be the one Poo-Pooing the whole > idea.
I would -1 a backwards incompatible change. However a new major version that threw compatability to the wind .... that would be kool with me. The main reason is that we have not broken back compatability yet except with one minor issue (serialized form of Configuration objects) which is one of the reasons I was able to get some local peeps to rely on framework. I really like the idea of it being stable - even if it has a few uglies. However if you recall back to our original discussions on ComponentManager vs ComponentSelector vs NamedComponentManager. I didn't really like NamedComponentManager or ComponentSelector and tried to stop it but gave up - it was 3 vs 1 and even I get bored of arguing ... well on very rare occasions ;) Personally I used to think hierarchial ComponentManagers was the go ... but I think your Query object is another interesting idea. > The issue is that we need to figure out what to do to handle n-dimensional > lookup. Is the Query Object idea worth persuing? Persue = yes, put in framework imediately = no. I think it is a good idea to look at this and it matches somethings found in some service directories. For instance it is similar to JMX where the "name" is essentially made up by a listing of attributes - so their lookup strings look like MyDomain:role=com.biz.Foo,type=DefaultFoo,capacity=3,... And you can search for services based on their attributes. > BTW, Such a fundamental change might require a 5.0 path for Framework. > That would allow us to clean some other stuff up in the mean time. Definetly. Other things work looking at * remove all deprecated stuff * reconsider removing Component interface * reconsider not having Initializable/Disposable in separate interfaces * consider adding a base class that implements all the activity interfaces * consider removing ThreadSafe and friends * consider adding a Level object to logger and extra methods log( Level, message ) log( Level, message, exception ) I already have a fork that does this. However it may be a good idea to change package names so I can continue relying on Framework4.0 until next version is ready. Perhaps something like org.apache.framework org.apache.avalon.framework2 or similar -- Cheers, Pete --------------------------------------------------- "If you don't know where you want to go, we'll make sure you get taken." Microsoft ad slogan, translated into Japanese. --------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
