On Jan 11, 2009, at 6:53 PM, mh wrote: > Steve, > > I suppose that in order to create useful TIM one should have good > knowledge of > Stripes internals. Having Terracotta experience would not hurt > either. Frankly > speaking we have neither. As I mentioned earlier one of the key > reasons for us > choosing Stripes was its effective simplicity hence the > productivity gains. The > same thinking brought Terracotta into consideration; the promise of > transparent > clustering (well, almost transparent) is very appealing. Developing > new TIM sort > of contradicts to the idea of simplicity. I am afraid that it's > beyond the scope > of our project and we have to choose from other options. > > Thanks for your feedback.
I think you have unrealistic expectations from complicated software. While both tools are easy to use, that doesn't mean that their aren't "nuances" that can effect deployment. Consider Stripes class loading mechanism. Yes, it's easy to use, but it also makes some assumptions on "how things work" in order to provide that ease of use. For example, there is a known issue with Stripes on Glassfish when running multiple WARs in the same deployment -- it doesn't work without some "nuancing". But that's an issue between Stripes and Glassfish, both "written to standards". Just the reality of complex systems. The TIM (being as I'm completely ignorant of Terracotta) seems more like it's similar to, among other things, adjust the what packages Stripes uses for checking for ActionBeans. You can start Stripes up without a list of approved packages, but you likely don't want to. Terracotta and Stripes may well simply work right out of the box, but in fact, Terracotta may well work better (possibly MUCH better) with a bit of tweaking and tuning and "nuancing". This kind of information is what Steve is suggesting might be an interesting project for someone in the Stripes community to take. His point being that IF a "informed Stripes" user were to take a stab at creating a Terracotta TIM file for Stripes, then it would perhaps provide a easier path for less informed Stripes uses that may wish to use Terracotta. The goal, obviously, to help lower barriers to using Terracotta for more applications and, ideally, boost usage of Terracotta overall. Powerful software like Stripes has the great ability to let you as a user be only as informed about it as you want to be, with it's layer complexity. But it would not be surprising if casual Stripes knowledge would not be enough to optimally deploy a Stripes system on top of something as invasive as Terracotta. Regards, Will Hartung ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
