On Thu, 2002-10-17 at 00:20, Stephen Haberman wrote: > > 1) Turbine 3 should never be released. > > Agreed. Turbine 3 never even made it past alpha, so while a migration > path to summit might be nice, I don't think it's required. I've got an > app using T3, but me and anyone else who started using T3 are the ones > at fault for using an alpha release in the first place.
I never wanted it to turn out that way, but that's what happened. I think if people looked at Summit, scrutinized the API by examining the UML and provided some use cases all the holes can be found pretty rapidly. I've got three already that I'm working on: o Cleanly providing a way to display binary info. RawScreen has always been a PITA and confusing as it's a screen with no layout which is a weird exception. o Inter application communication for aggregation and portals. The Jetspeed use case again. Hopefully David Taylor will help me with this one. o Multiple view types where you might be displaying HTML, XML, WML, SWF or whatever. Displaying the different types isn't hard but how best to organize this for a single app trying to display to many devices. Ilkka has this covered so I'm definitely going to lift things from Tammi. > > 2) Fulcrum should never be released. > > Agreed. Fulcrum is nice, but Avalon is better, so going with the best of > breed is a clear choice. There's no competition here. It's incomprehensible and that's after several big cleanups. It's just not that good: the code or the interfaces. Avalon wins hands down. > > 3) Torque doesn't hold a candle to OJB. > > Agreed. I shortly came into Torque awhile ago and had been hoping to > help clean it up, refactor the implementation and what not, but the code > base is all over the place. > > I think a 3.0 release is good as lots of people are using it and it's > been in beta for awhile, but after that, we should make it very clear > that there will not be a 4.0 version. > > Torque's three main features are Java code generation, DDL generation, > and persistence. DDL generation is being handled very nicely by > commons-sql, persistence is handled nicely by OJB, but as of yet, there > isn't really a Jakarta project for Java code generation. Instead of > making this an argument for keeping Torque around, I think a separate > project, if individuals are so inclined, to handle Java/UML > forword/reverse engineering would be awfully nice and could then perhaps > do the sort of stuff Martin was talking about implementing (e.g. > generation of Swing/Turbine front-ends based on a model). OJB has some forward/reverse engineering tools and there are soon going to be some in commons-sql. There are all kinds of people doing this stuff but hopefully all this stuff will coalesce. There is also some bean generation stuff in Jelly that came from stuff I am working in Tambora. There are tons of people working on stuff and tons of options. Something with Jelly or Velocity is probably the best bet. > > 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. > > Readily agreed. I almost started a new app on JPublish as the docs > impressed me and it seemed like a cleaner, smaller Turbine. Though on > closer inspection, unless I'm missing something, it didn't seem as > powerful as T2/T3, and it worked out the new app has been pushed off a > bit so I can cross my fingers and await summit. Turbine has some really awesome ideas. I still think to this day the resolution mechanism is very powerful just not expressed very well I don't think. I didn't change the idea at all in Summit, I think I just have expressed it better and provide an arbitrary resolution mechanism. For example the ClassicResolver takes a target view and resolves sibling views (layouts and navigations), and modules that might populate a context of some sort, say a velocity context. But with Summit I think it's now pretty straight forward to make different resolving mechanisms. One I hope that is developed is one for Jetspeed and it's portal requirements. > > 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. > > I like that you're working on summit. But, I dunno, how does the Turbine > community come out of this? With Torque, Maven, and Fulcrum all > potentially leaving Turbine's umbrella As long as users are satisfied and a decent upgrade is provided does it really matter where the code goes? If it all got folded into Avalon that would be fine with me. If people want it the name of Summit can be easily changed back to Turbine: I just picked a new name because I'm not making any assumptions about its acceptance. I do care about the community: The TDK never really did me any good (maybe it didn't do anyone any good), I made it for users and I am still the only one who has ever cut a final release of Turbine, ever. I don't care where the code goes but I would like the ideas to survive somewhere. > , perhaps even JCS moving to a > commons/incubator area, I really like that Turbine would be focused > solely on being a web framework and only a web framework, but I guess I > don't know enough about open source yet to figure out how/if/when the > various committers and users will circle the wagons and become a real, > active, effective community again. Turbine can be that. Summit is actually more geared toward providing a web-based view for an application model. I would like to encourage the development of solid application models and use Summit for any web-based views. It could certainly be used like Turbine currently is but I think there are better ways. Especially when you discover you want a Swing/SWT front end and you have your logic tangled up in a data model or in web specific classes. > I rallied against the lack of community in Torque awhile ago, much as > Scott Eade is now, and though I dearly sympathize with him, when I was > given the chance to fix things via commit access, I've steadily realized > just how bad the situation is. It's really hard to build a community of > committers around such code bases; maintaining old, crufty code just > sucks. Turbine has been around for a long time and it's natural that things come to what we have now. Lack of tests and entropy won this time IMO but there's absolutely no reason the ideas can't live on in something new. > As stated above, I'm in full agreement with your previous statements to > the affect that the entire Turbine subproject code base needs rehauling; > I'm just hoping that/wondering how an injection of good, clean, tested > code will invigorate the community. We'll see. I think Summit is small enough that it can be comprehended a little easier. It's completely javadoc'd and I will make another pass and I am working on the documentation. It's part of my full-time job to document Summit as part of the Tambora effort. I certainly also want to work with Ilkka and try to combine Tammi and Summit and I think we'll come out with something that deserves to be at Jakarta. > - Stephen > > > -- > 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]>
