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.
