> I think I > would tackle making Torque a component which will mean > cleaning up its initialization mechanism unless it's changed > since the last time I looked at it. At my last glance the > whole show was start by nudging the Criteria class which is > just plain wrong.
It is pretty clean now. Most of the work will probably be converting the Avalon Configuration to a Commons Configuration. Are you aware of any code that's already doing that ? > > I have been thinking about Torque + Avalon for a while now > and I don't > > see a clear way of getting rid of the extremely static nature of > > Torque without a complete redesign (for which I have no time). > > Yes, that's a problem but probably not insurmountable. At > first we might have to say that it looks like a component but > that you can only run one instance safely. Yeah, sounds like a solid short-term solution. > > The only thing I can think off (and which I will hopefully > get around > > to doing this week) is writing a simple Avalon wrapper that > only makes > > sure the static Torque gets configured and initialized. This hardly > > seems compatible with the Avalon way of things :( > > No, but it's a start. Torque is highly problematic in a > component-based system but we can work around it. People have > for years now so it won't be anything new. I'll get to work then :) Age --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
