Torque as an Avalon component ?

[Age Mooy <am...@home.nl>]

Hi,

I would like to start converting Torque to Avalon. I know this topic has
been discussed before on torque-dev and turbine-dev, but I don't think
any conclusions have been reached. Is anyone working on this ?

As I see it, there are three basic options for making Torque compatible
with Avalon:

1)
Write a simple component wrapper around Torque that takes care of
configuration and initialization and delegates all method calls to the
static Torque class.

2)
Redesign the current Torque class into a "real" avalon component
implementation, getting rid of all static methods and Stratum
interfaces. This would severely break backwards compatibility and would
need a lot of work, esspecially on the whole concept of static Peer
classes, because then Torque can only be accessed with the aid of an
Avalon ServiceManager/ServiceSelector

3)
Combine 1) and 2) by doing a full implementation not named Torque.java
and making the Torque class a simple static wrapper that ensures
backwards compatibility. The problems mentioned for option 2 still apply
here though.

Option 3 would keep the most people happy I guess. But option 2 and 3
require a lot of discussion about the use of static methods and static
Peer classes in Torque, not to mention a lot of work. One of the biggest
questions is: how would client code that doesn't have access to an
Avalon ServiceManager get access to Torque ? Maybe we could write a very
simple Avalon container

What do you all think ?

I have time to implement at least option 1 and I need some way to load
torque as a component anyway, so I volunteer for that. This is what I
propose:

- a TorqueService interface with non-static versions of the relevant
methods in the Torque class
- a DefaultTorqueService class that implements the Avalon lifecycle
interfaces, and delegates everything to the Torque class

Would this be acceptable ? Should this go in the org.apache.torque
package or in a sub-package ?

Regards,
Age