Hi, have you forked it and made it RBX usable ? Would like to test some of our production merb apps in that case.
We are running under 1.8.7 MRI Anyone on 1.9.2 ? (or even 1.9.3) Can spare a few week hours helping merb. Go for tickets ? Best regards, pedromg On Mon, Jul 4, 2011 at 10:55 PM, Xavier Lange <[email protected]> wrote: > I've been hanging out in #merb on irc.freenode.net and discussing my > work on bringing Merb in to the future. To be clear, the merb project > is suffering from code rot. I have had to create patches to support > memcache session storage, fix definitions to play nicely with bundler, > and more. The big lesson here is that Merb should look to rely on > stable APIs from libraries with more active maintainers. > > I want to keep Merb a lightweight, straightforward MVC framework > (great for hacking, already have a production app working with it, > etc). Now we have to discuss what bits of code to rip out and what > libraries to inject instead! Since we're relying on Rack we can get a > lot of high quality software (and the inevitable updates) for free. > > Nicos has been scratching similar itches and he recommended that I put > my ideas down on the mailing list. Here it goes: > > a) Fix class loading so we can boot on the Rubinius VM in a reasonable > fashion. The big problem is that Merb's reloader bangs on ObjectSpace > to see what definitions have been added/changed. This functionality > could be written using reloader code from autotesting libraries. This > is a show stopper for me because I am moving all my infrastructure to > RBX -- it will fixed ASAP. > c) remove custom rack adapters > We should instead encourage config.ru usage with rackup or any other > server (unicorn, thin, etc). New servers come out all the time -- but > the unify factor is they all support rack. > d) remove session code and instead plug in to rack session system > Since Merb will become yet another rack-friendly framework, we should > piggy-back on a session store which can be easily mapped across > frameworks. We should look in to using Rack::Session, they support > cookie and memcache. I would probably end up writing a redis-based > session store as well. > e) Remove Merb's multipart parsing > Rack has multipart parsing support ripped out of IOWA -- we should use > that and make our code simpler. > f) Make Merb application instance based rather than class based. Right > now we have Merb::SessionStore.store, Merb::Router.routes, etc. We > should instead make it descend from an instance of a root class. I'd > like to boot multiple Merb apps in one instance of RBX. This is a long > term goal. > g) Built in profiling hooks for RBX. I'd like to provide either an API > for performance tracking, or just add some choice profile statements > in to Merb's boot and request dispatching. Medium-term goal. > > Nicos has done some good work on simplifying merb-gen by transitioning > to more supported libraries like Thor. He's also doing some good work > on transitioning away from extlib so we can just ride the wave of > ActiveSupport and get their updates for free. I know extlib is holding > some people back from using new libraries. > > I welcome everyone's feedback on this matter. > > Thanks, > Xavier -- You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/merb?hl=en.
