Another Rails 2.x/3 Update

I didn’t get that much done today on the Rails front as a result of getting Merb 1.0.7 out the door. I did do some more planning about how to clean up and improve the performance of ActionPack, and am really looking forward to diving into the work tomorrow.

Daniel (hassox), Michael (antares), and Carl (carllerche) have been hard at work today:

Daniel has been porting over the Merb Bootloader concept into Rails’ initializers. This is a 100% backward-compatible change that will simply make the initialization process easier to hook into (especially for plugins). This is one of the crucial components necessary for good ORM agnosticism. You can follow along at his branch. This turns out to be fairly difficult so kudos to Daniel for picking up this piece of the puzzle and getting right at it.

Michael has been going through ActiveSupport and working to make it more modular. His first major achievement is getting a new activesupport/mini.rb file that can be used by other libraries that want extensions, with a guarantee that it won’t pull in any more than is explicitly included. It includes blank?, Object#metaclass, Array extensions, Hash extensions, *attr_accessor, multibyte support, and inflections. Additional components can be required granularly, and of course, each of these components can be included granularly as well. activesupport/mini is intended to be a lightweight starting point (it weighs in at just 2.5MB) for the most common cases. Michael plans to move Templater, which currently uses Extlib, over to AS once 2.3 is released.

To quote Michael:

On the ActiveSupport front, we separate Rails-specific dependencies from others, so 3rd party applications do not get extra overhead. Right now in 2.2.2 if you do require ‘active_support’, it loads a lot of Rails specific code, like i18n gem, Builder and ActiveSupport::JSON. Since there are Ruby applications that need a convenient support library, but do not deal with the web, JSON and Builder are pure overhead, and should be loaded by the Rails components that use them.

In a follow-up to the very simple example I gave yesterday in annotating metaprogramming, Xavier Noria (fxn) went in and annotated all of the metaprogramming in the entire Rails codebase! Check out the commit. It should make it a lot easier to understand the metaprogramming sprinkled throughout the Rails codebase. Thanks to antares for the initial inspiration.

Carl has been doing some killer work to make the Merb router more flexible, and capable of handling Merb1, Rails2, and a potential Rails3 syntax with the same backend. It’s going to be really awesome to get the feature-set of the Merb router (optional segments, routing based on arbitrary request elements, inline custom code, etc.) into Rails with a shiny Railsish API. David (dhh) is already doing some killer work on designing an API for the features in the Merb router that aren’t yet in Rails that looks very promising.

We’re beginning to see that a large amount of the work that we’re doing is 100% backward compatible and can easily make it into 2.x. There’s a chance there will be a 2.4 release sometime between 2.3 and 3.0 just to roll in compatible features and cleanup, so we don’t dump the entire new feature-set on you in one fell swoop. We’ll see how that goes.

I have a small change ready to be merged into rails/master that unifies three places that did content negotiation throughout the Rails codebase. I have more work to be done on this front, but it’s a lot clearer what needs to be done now that the small bit of refactoring is done.

I hope to have some stuff on ActionPack in tomorrow’s update. I’m really looking forward to my first full work-day on Rails at Engine Yard.

See you tomorrow folks!