[Nitro] Interesting web framework article

Kirk Haines wyhaines at gmail.com
Wed Feb 21 11:47:42 EST 2007

On 2/21/07, James Britt <james.britt at gmail.com> wrote:

> The problem I've run into with mixing up assorted framework parts is the
> conflict of libraries.  For example, one *should* be able to use Rails
> view and controller parts with Og, but I've never gotten it to work.  I
> think facets or glue get into arguments with ActiveSupport of actionpack
> or something.

Chris and I discussed that issue.  It's a framework implementation
thing, though, and doesn't necessarily negate his point, which is that
if one has nicely behaved code that respects namespaces, rack makes it
easier to have one process handling more than one framework.  I think
this is only a small point in favor or rack, though.  I don't think
that use case is particularly common, unlike your use case.  I think a
lot of people would love to mix and match Og/Rails or AR/Nitro.

> It would be nice if the Web end of stuff was abstracted from the app end
> of stuff, but then the app stuff needs be cleanly decomposable as well
> and each supporting library cleanly name-spaced, .

The name spacing issues are big ones, and I think this will remain an
issue for any Nitro/Rails component interactions, since Rails doesn't
respect namespaces, and Nitro, by depending on Facets, doesn't really,

On the larger issue of the benefits of rack, though, I have been
wrestling with that.  I think the benefits are minimal for an existing
framework like Nitro or IOWA or Rails, where everything that rack is
doing, the establish frameworks already have established mechanisms
for handling.

Nitro already has a well defined way of representing requests.  IOWA
already has an established API for responses.  Rails already has
standards in place for how logging is handled.

So, supporting rack means either changing these well defined things,
or adding some sort of compatibility layer, which in turn adds a layer
of indirection and inefficiency to the code.

IOWA's run mode support is very modular, so I am planning on
supporting rack in exactly the same way that I support other run
modes, and I'll take a wait and see approach.  If people start
developing useful functionality that uses the rack API. that will be
usable without me having to change my internals.  There isn't much
risk to this approach, and IMHO, it is one that I think George should
consider for Nitro.

One thing that I have wondered about is if two frameworks, for example
IOWA and Nitro, both supported using the rack request/response model,
if it would be easier to write reusable widgets that worked for both

Kirk Haines

More information about the Nitro-general mailing list