On Tue, 2002-10-15 at 21:28, Rodney Schneider wrote: > Hi all, > > I just found these IRC logs yesterday and what I read explained a lot about > what has been going on in the Turbine community: > http://irc.werken.com/channels/turbine/ > > Essentially... Jason, Jon, John, Daniel, Eric, Henning et. al. seem to have > different, possibly irreconcilable opinions about the future of Turbine, so > some of you seem to be pissed off, disillusioned and confused about what to > do. Please correct me if I am wrong.
I myself am neither disillusioned, nor pissed off. I have basically decided to step back for a while to focus on Tambora and plod away making an Avalon-based version of Turbine. > These three threads; "How Avalon might change Turbine", "Turbine 3 direction" > and "Turbine Road Map" also explained things: > >http://archives.apache.org/eyebrowse/BrowseList?[EMAIL PROTECTED]&by=thread&from=210342 > >http://archives.apache.org/eyebrowse/BrowseList?[EMAIL PROTECTED]&from=208709&to=208709&count=42&by=thread&paged=false > >http://archives.apache.org/eyebrowse/BrowseList?[EMAIL PROTECTED]&by=thread&from=210179 I don't think there are any major disagreements. I was mildly irritated with some comment from Henning insinuating that the code base was treated as a personal playground at which point I just kept my mouth shut. I think the conversation in the threads above were fairly aligned in opinion. > I missed all of these discussions on turbine-dev as I was busy working on my > application and I wasn't subscribed to this list at the time. As most people are. This is a typical problem with Turbine in that it is a volatile beast. > It would be really helpful if each of the main Turbine committers could write > a short email to this list outlining their current position with respect to > contributing to Turbine. I don't want to start a flame war or even start a > discussion about the future of Turbine. There are many talented developers > using Turbine, and at least some would contribute if they knew what was going > on. So, if you are a Turbine committer, please consider stating your > position. Here's a starting point: > 1. Are you busy elsewhere? If so, will you continue contributing to Turbine? Yes, working on Tambora, Plexus and Summit. I will leave it up to the developers and users to decide if they would like to use Plexus and Summit. > 2. Have you moved on (ie: permanently left the Turbine community)? No. > 3. Will you resurface soon with an alternative to Turbine? I gave the first demo of Summit today. > 4. Will you help maintain Turbine 2.x in the future? I am certain now that I can get Turbine 2.x applications to run on top of Summit. Summit is basically a fully refined, cleaned up version of Turbine 3. It's very flexible and is currently sitting at a hefty 60k. Turbine 3 applications could also sit on top of Summit though that's not my particular concern. Turbine 3 was an experiment that went very rapidly at first but dovetailed into my realization that the whole mess of Turbine code was going fall off into the ditch without some help. That's when I started Maven. Maven is now something that I didn't expect but the primary impetus for me was an attempt to help the Turbine community for better or worse. Worse mostly from the number of complaints the Maven builds garnered. > Anyway, after thinking about all this, I have decided that after I migrate my > application to TDK-2.2b3 (I've been a bit distracted the last couple of days) > and write the migration howto, I am going to work on the coupled > SecurityService rather than Henning's DBSecurityService proposal or the > current Fulcrum SecurityService as I am not overly confident that Fulcrum > will be around for very long after Jason has finished Plexus. Plexus is fully functional and currently has the following components/services: ( ) JCS Component (* ) Jetty Component (**) JMX Manager Component (**) Persister Component (using OJB) (* ) Scheduler Component (using Quartz) (* ) XMLRPC Component (* ) Transactor Component (General messaging/uses above 3 components) (* ) Velocity Component (* ) Summit Component (not fully avalonized but needs Plexus) * - fully functional and used in the demo I just did today ** - will work in the next 30 days > I figure that if I can get the coupled T2.2 services into a decent working > state, it won't matter what you guys decide to do with Fulcrum. Then, at > least the people over on turbine-user will be able to upgrade to TDK-2.2 with > the decoupled Torque, which is a reasonably stable and maintainable codebase. > Am I completely crazy or am I making sense? Yes :-) If the majority of people are still using the couple services then I would be willing to help to extract the service code and make it work with Summit. IMO, Fulcrum is a dead-end. The code that is valuable like Intake and Localization goodies can be shunted into the commons and used from there to make Avalon components. At any rate all the stuff I've been doing are in visible repositories, actually everything is in the Plexus repository now: http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/ And the Summit UML/Javadoc is here: http://www.apache.org/~jvanzyl/Summit/ In summary I think aligning ourselves with the Avalon folk is our best chance at survival. Some of my other opinions include: 1) Turbine 3 should never be released. It is stable but it is a piece of crap. I know this better than anyone because I'm the one who stripped it down. The API is still far from decent and carries much baggage still from Turbine 2. With very little change to code all valve and pipeline implementations used in Turbine 3 can be used in Summit. 2) Fulcrum should never be released. Again I know because I spent too much time decoupling it. I regret now ever decoupling Torque and Fulcrum. Anything in Fulcrum can be changed into an Avalon component/service in very short order. 3) Torque doesn't hold a candle to OJB. No commercial or OSS persistence layer even comes close to what OJB offers. I've explained this numerous times in numerous places. The original Jakarta proposal outlines many of the critically import features. A simple example is the LargeSelect stuff I see flying by the list: this was designed into OJB from the ground up with lazy materialization and the use of proxies. 4) I don't care about applications developed with Turbine 3. I want to be able to move the majority of users using 2.x forward. I know this can be done with Summit. Summit captures all the unique features of Turbine while getting rid of all the crap (maybe I added some new crap, but all the old crap is gone :-)). That's my opinion but look at the UML and judge for yourself. I see Turbine 3 as an experiment and nothing more and I believe it is unfortunate that it got used for things like Scarab. 5) Turbine has a unique place in the webapp development space but we're going to get pummeled by frameworks like JPublish and Webwork if we don't get our shit together. Our salvation, I think, has been the Jakarta moniker. It's not that Turbine is bad, but the docs suck and the code has fallen prey to entropy. How many of you know how Fulcrum actually works? How many of you know how Turbine 2 actually works? How many of you actually know how Turbine 3 works? If there were some docs you might be able to explain it to a co-worker but I know for certain if you had to look at the Turbine 2 code you would throw up your hands and scream "What the fuck is going on!". If anyone actually figured out how a module was resolved in Turbine 2 in less than four weeks I give you an "I conquered Turbine" t-shirt :-) I think we have to be critical about what we have and where we want to go instead of trying to push code that just isn't that good. I know that Fulcrum and Turbine 2/3 aren't that good. I would say that technically they are excellent. Jon and John (who are primarily responsible for Turbine 2) are two of the best technical programmers I know. They can make anything work. The proof is in the fact that Turbine 2 has no tests and is very stable. By my estimation in talking to about 40+ developers the average time to comprehend Turbine 2 fully in between 5 and 8 months. That's just too long. But the design leaves a lot to be desired and I'm very responsible for many of the worst ones. The unified template service in Fulcrum is a disaster and is my fault entirely. It's virtually impossible to follow. The security service is also another disaster. If someone harvested the email and searched for the issue attracting the greatest number of gripes the security implementation would probably win. It's time to stop patting ourselves on the back and cull the herd. That's pretty much where I stand. I'm going to continue with Summit and make a Maven plugin for generating apps and there's a small sample app already in the Plexus repository. If people don't want to use it that's cool with me. I haven't started using it for Tambora 3 as the API is going to be scrutinized over the next two weeks to try and hammer out any missing details so you're welcome to join in. I will continue to update the UML/Javadoc. If you checkout the plexus repository you can generate the Maven sites for Plexus and I will publish the whole thing somewhere soon. There's a reactor for building the Plexus site and all the components. > Once again, thanks for all the hard work you have put into Turbine over the > years! Hopefully it will continue in one form or another :-) > Regards, > > -- Rodney > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
