Hi, I'm sorry to put in my opinion before Robert's but it always seemed to me that the "java_servlet-rails" bridge related classes could be extracted off to a new common project, and deployment related things to a bunch of container-specific subprojects (or completely different project, but I'd say subprojects).
The "java_servlet-rails" bridge could even come in the form of a jruby-gem. Just my two cents. Robert? Cheers, Fausto. On 5/28/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Jruby-extras-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/jruby-extras-devel
