> My intention is not "being compatible to Torque" but "keeping the
> style of the Turbine OM system alive while attacking the inadequacies
> and shortcomings of the current system. I HATE THE STATIC PEERS FROM
> THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
> people who want to use it.

This feeling is shared by a good number of people.  I started on
changing it a couple times, but have not had time to every complete it. 
Glad you are volunteering to take it on.


> Ideas I will work on from the README.txt
> 
> --- cut ---
> o Torque should be fully functional on its own, but right now
>   it doesn't work as a persistence layer without the DBService
>   in Fulcrum. The classes should be moved from Fulcrum into
>   this repository and Torque should be made to work on its own
>   and be embeddable in applications. The DBService in Fulcrum
>   should be a wrapper around Torque.

I thought jason has already taken care of this, but maybe there is still
a little work to do.

> 
> o Separate the connection pool and make it pluggable
>   so that torque can easily be integrated into other application
>   that already use PoolMan, or the commons connection pool, or
>   the struts connection pool or whatever

I have been working on this and most of the code in the JDBC2POOL_BRANCH
tag of torque.  The pool has been updated to jdbc2 compliance with an
adapter for non-jdbc2 driver implementations.  The main issue still left
to be worked out is setting jndi properties for the initial context.

john mcnally

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to