wyhaines at gmail.com
Mon Feb 5 11:18:07 EST 2007
On 2/5/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> Yeah, I'll be bringing this and other stuff up on the Mongrel list, but my comment
> was more that framework developers tend to assume they are THE ONE TRUE
> FRAMEWORK and don't play well with others. It's be nice if they assumed
> otherwise and then it'd be easier for Mongrel to at least run multiple instances of
> the same framework but different apps in small installations.
(*nod*) Some frameworks more than others. AFAIK, Nitro, at least
prior to the dust settling on what they decide to do with config
settings, generally keeps it's stuff in its own namespaces, with the
exception that it uses Facets, and Facets and ActiveSupport generally
stomp on and mess with eachother in incompatible ways, which presents
difficulties getting Nitro and Rails to be good neighbors.
IOWA tries very hard to keep everything in its own namespace, and is
very close to having everything in place so that multiple applications
can live together side by side, so I'm with you on this one! I think
the benefits of a framework having some consideration for the
potential of having neighbors inside the interpreter outweigh the cons
(which, in my experience, are very minimal), and I wish more software,
in general, was written with an eye towards being a good neighbor.
I made some comments on the IRC channel about this config issue. I
think it is in Nitro's best interest to stay away from a sea of things
that look like $perl_variables for three reasons:
1) PR. Ruby people generally don't like the stuff that looks Perlish
(though the people who come to Ruby from Perl don't tend to care
much), so a lot of $variables_like_this is going to come off to many
people as ugly and backwards, regardless of what the real merits might
2) Issues with owning the whole interpreter, which is what you are
getting at here. It's easy to think that Nitro is going to be by
itself in the interpreter, but there are potential benefits in having
a Nitro app that can be a good neighbor with other frameworks.
Filling the global variable space with config variables isn't
3) It makes it all but impossible to migrate from that point to one
where one could have more than one Nitro application living side by
side, regardless of what the other architectural issues in that may
be. It's a showstopper. Even something like $nitro.config_item is a
workable compromise there because it could easily integrate something
like $nitro['app1'].config_item if Nitro ever moves in a direction to
allow multiple side-by-side applications - there's very little
paradigm shift there.
> As for Sandbox, it'd be great but currently afaik it's horribly slow.
I figured it probably was. Too bad.
More information about the Nitro-general