On Mon, 2003-03-17 at 08:46, Age Mooy wrote: > > > I think that users will be very > > > hesitant to move to a new version of Turbine if the > > development effort > > > is very high. > > > > I'm shooting for as close to zero code changes as possible. > > Can you give us any idea about the use of Torque in Turbine 2.2/2.3 apps > and how that will work in Summit ? Most current Turbine apps heavily > rely on Torque object models.
Turn torque into an Avalon component as has been suggested would be a starting point. I don't expect everyone to move to OJB even though that would be my suggestion for the future. > I have very briefly looked at the Persister component in the plexus repo > but it looked far from complete and only applies to OJB. Do you plan to > support the use of Torque in some way ? Torque will probably become a separate component and the persister will probably be renamed to OJB like. I think I'm done with trying to create uber interfaces like the Template service. I think the persistence components can be separate at first and the commons persister contract can be worked on later. The contract is not so hard when it comes to the most operations but the query mechanisms are radically different, even within OJB you can use three different models. 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. > 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. > 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. > Age > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
