Merb Tasks

[Xavier Lange]

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

[ngo...@googlemail.com]

And now for my part of the conversation, to have things from IRC written down :-)

Xavier Lange <xrl...@gmail.com> wrote:

> 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.

That should, in fact, work right now in the active_support branch. I've been playing with the config.ru generated for the "stack" application, and it seems to work out of the box with "raw" rack and thin, so dropping the custom adapters might be as easy as doing "git rm" and writing a few lines in the changelog. Most of the Rack code is just there to deal with deferrable codepaths, some works around issues in servers that are probably resolved, and most of the work done in Merb::Rack::Application is error handling and working around the fact that the Merb stack handles the concept of a Rack response rather loosely. (IMO, the requirement of having the body respond to #each is weird.)

> e) Remove Merb's multipart parsing
> Rack has multipart parsing support ripped out of IOWA -- we should use
> that and make our code simpler.

My take is that dropping multipart support from the project scope might cost us. From what I've seen, Rack's multipart handling is very much focused on "binary blob" file uploads. This is fair, assuming the client is a browser. However, in that process, some potentially vital information like charsets get lost, and it also restricts the nature of incoming requests.

When I started hacking on the multipart parser, I did that under the premise to make it the point where incoming data, when possible, gets properly earmarked with its charset or converted to UTF-8 (using the encoding capabilities of Ruby 1.9). In my opinion, having a "UTF-8 clean" side of the stack would be a boon, and allowing more complex requests than just blob uploads might be interesting to people working with more complex clients.

It would probably make sense to try and get that into Rack though :-)

[pedro mg]

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

[ngo...@googlemail.com]

On , pedro mg <pedro...@gmail.com> wrote:
> have you forked it and made it RBX usable ? Would like to test some of
> our production merb apps in that case.

rbx (and pretty much all "compliant" Ruby VMs) should ideally work. There shouldn't be many real issues, other than class loading taking a long time and currently a rather esoteric problem in the "Thorified" merb-gen.

> We are running under 1.8.7 MRI
>
> Anyone on 1.9.2 ? (or even 1.9.3)

I'm developing mainly with 1.9.2. It's likely that merb will depend on the encoding functionality in the future.

> Can spare a few week hours helping merb. Go for tickets ?

The best you can do is put some real applications on the active_support branch in git and Make Things Work™. Don't be afraid to break the API when it makes sense. It'd be great to see contributions from that angle. Drop by the IRC channel if you want to, UTC evenings should be good for that.

Maybe I should just open the issue tracker on github. Might give a cleaner view than the rather stale Lighthouse tracker. Thoughts on that?

Regards,
Nicos