The right Ruby runtime [was Re: Notifications between Aeolus components]

David Lutterkort lutter at redhat.com
Tue Jan 22 17:42:26 UTC 2013


On Tue, 2013-01-22 at 09:57 -0500, Scott Seago wrote:
> On 01/22/2013 08:01 AM, Michal Fojtik wrote:
> > On 01/08, Hugh Brock wrote:
> >
> > Maybe a crazy idea, but Torquebox already includes messaging, background
> > jobs, services and all other things mentioned in the original email.
> >
> > I have PoC of running Conductor inside Torquebox (using jRuby). I
> > understand it might be a big step but definitely worth to at least
> > investigate as an option :-)
> >
> > Just my .20cents.
> >
> >    -- Michal
> >
> We've talked about using torquebox on-and-off over the last couple 
> years. The growing consensus there seems to be that we do want to be 
> able to run on it, but not at the expense of getting locked in to using 
> _only_ torquebox.

One of the things that makes Ruby so thorny is the endless number of
runtime/deployment options: starting with the interpreter, through to
the app server, there's lots and lots of variations, most of which suck
in one way or another.

We are using MRI basically because it is the default, and thought to be
widely adopted. Especially MRI 1.8 had little redeeming features beyond
that - we'll see how 1.9 will blow up differently.

It might be a good exercise to agree on a set of requirements for our
Ruby env, and then try to figure out which of the options best fits our
needs. It would be great if we could close the door on 'you can
develop/deploy in these 10 ways' and just settle on one environment. 

The fact that lots of 'stuff' is available in Torquebox right off the
bat makes it very attractive - though there may be other reasons why
it's a no go.

So here's my list of runtime requirements:
      * Ease of setting up a dev environment on important platforms
        (Fedora, RHEL, OSX, maybe Windows) and of using it
      * Ease of production deployment
      * Stability for production (anything that's not stable in dev
        isn't worth considering)
      * Availability of gems/libraries/addon functionality

David





More information about the aeolus-devel mailing list