On 11/15/01 12:05 PM, "Mike Haberman" <[EMAIL PROTECTED]> wrote:
> Jason, > > I can back out the stuff if it upsets you that much. No biggie. > I will get on the IRC to clear things up. > > But the caching mechanism is put in the DefaultResolver which > can easily be not used. I not changing stuff all over the place. > Your architecture and design goals are well in tact. Everthing > is still decoupled--- If you don't want the cache in there now. > fine. > > I didn't put the caching in help performance for me. I did it > so that we can keep moving on T3. > The movement of t3 has many facets. I consider working on the testbed for Torque and Fulcrum integral parts of moving forward with t3. What I am most concerned about is adding complexity that performance enhancements may introduce, and the addition of more code that has no tests. While creating the testbed for Torque we find problems almost everytime we make a new test. We don't need more additional code right now. Jon made some additions to the t3 code the other day, and even though he didn't have to, he gave me a heads up about the changes because he's sensitive to my often over protective stance toward the code in t3. I'm am not trying to intentionally hold anything up, but I think it is a fact that the 3.x code wouldn't exist if I hadn't done the work and though I am tied up with Torque and Fulcrum (plus working full-time on Tambora) I still want the opportunity to finish it. And I will but the fundamental shortcoming is that I haven't documented much. That is solely my fault and I'm trying to remedy the situation starting with Torque but it goes slowly while working on another project full-time. We have also batted around the idea of basing Turbine on Avalon which has its own implications and would affect the design of the t3 code. This is far from decided but it's another factor to take into consideration. I think the t3 core should pretty sleep until the decoupled Torque and Fulcrum can be used with 2.x and 3.x at this point I think it will be much easier to work on t3. The migrator is also working but performs a limited set of transformations. I myself have many different versions of turbine lying around that do subapps and work with BSF but I don't any point in checking anything in until we have a path to follow. Most of the changes occuring today are happening in Torque and Fulcrum and if we can get users working with the decoupled versions than I think it will be much easier to move them toward 3.x. But until than I would pretty much like to see the code left alone. You needed some changes and Jon needed some changes and a few tweaks for dire requirements are fine (though I've stated that I strongly disagree with the use of t3 code in development cycles) but any more than that I think is harmful at this point. Again I think the course of events should be: 1. Torque testbed completion, documentation and release. 2. Fulfrum testbed completion, documentation and release. 3. TDK will integrate the use of the decoupled Torque and Fulcrum. 4. TDK can be tested and released. 5. Work can continue on t3. That's pretty much where I stand. -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
