It seems to me there may be many other good ways to implement GoldSpike. Whether it's the configuration format, the way rails maps to a servlet engine (or no servlet engine at all, as in the Grizzly Rails module), or how it retrieves, allocates, and manages resources (including JRuby instances), there's a lot of variability here.
It also seems to me that GoldSpike has become somewhat set in its ways. It has had a 1.0 release already (somewhat prematurely, in my opinion) and although it seems to be working really well, a 1.0 release always seems to kill new innovations. I propose a friendly fork of GoldSpike in the same repository, to allow more drastic changes to be experimented with, and potentially full rewrites of key pieces to happen. This would continue to live under the jruby-extras umbrella, and would be regarded as a research project. There's always the possibility the changes would be excellent, and the new GoldSpike would become *the* GoldSpike, but at the very least it seems like we need more diversity in this area. Remember folks, the OSS rule is that your implementation is worse than the one coming tomorrow, and more diversity is a net gain for the project as a whole. We need to foster more diversity in the area of rails-in-a-WAR-file. So who would be interested in making the fork and running away with it? I know a few of you have had good ideas that maybe didn't fit well into the current GoldSpike design. If you have commit rights, I highly recommend you pull off a branch and try your ideas out, and invite others to join in or do the same. - Charlie _______________________________________________ Jruby-extras-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/jruby-extras-devel
