Hi all,
> > > 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. Sorry for repeating this question (yes I know I could go through the Fulcrum CVS repository and compare it to the T2 repository, or go through the commit messages in the mailing list archives), but I am hoping someone can save me some time... How much of the code in Fulcrum has been backported to the T2 services? In other words, how much work do you estimate it would be to get the coupled T2 services up to date with the Fulcrum services? Have the two repositories been kept in sync? The main services I am wondering about are Intake and Security as they seem to be the ones that most T2.1 users depend on. > Turbine has some really awesome ideas. I still think to this day the > resolution mechanism is very powerful. That's definitely what attracted me to Turbine and why I spent so long learning how to code on top of the Turbine code base effectively. > 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. TDK-2.1 was far better than anything else that was around at the time... it has helped many a user learn Turbine and many of us are still developing with it (or a customised version of it). Not many developers would have ever been exposed to the Turbine ideas if there was never a release. > 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. Haven't most Turbine users been keeping their application logic within Turbine services and using pull tools anyway? It has always been considered bad practice to put your application logic in your Torque objects or Peers. I guess there are still some situations where the module/template approach is more appropriate than pull tools, but even then the modules should still be talking to Turbine services, rather than containing the application logic themselves. When you say you want to "encourage the development of solid application models", I guess what you mean is that developers should keep their application logic contained within reusable components/services? Sorry for the rant, I'm just trying to understand and I'm thinking out loud at the same time. Regards, -- Rodney -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
