[Mongrel] swifty fly?
wyhaines at gmail.com
Tue May 22 13:25:32 EDT 2007
On 5/21/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> There's was quite a few announced "mongrel needs some help" kind of
> * Swiftiply by Kirk Haines (as he mentioned)
Really, when I started writing this code, it had nothing at all to do
with Mongrel needing anything. It was simply about building a fast
clustering proxy that would work well with IOWA's implicit session
capability and would be available before Swiftcore IOWA 1.0 is
I only came back and added the swiftiplied_mongrel because Mongrel is
a target for all of the current existing Ruby frameworks, so it was a
path of least resistance for making Swiftiply available to those
frameworks, too, and I actually included evented_mongrel kind of as an
afterthought. I had to implement it, anyway, to get to
swiftiplied_mongrel, and there had been talk elsewhere about what a
Mongrel that ran in an event loop might look like and work like.
Turns out it was pretty simple, and it works pretty well.
> A big thing about all three solutions is they are auto-configurable in
> that you fire up mongrel nodes and they tell the proxy about their
> existence. In a shared hosting environment this is a total disaster
> for security (since anyone would just join your proxy without proper
> encryption and security involved). BUT, for people doing deployed apps
> like most of the above authors, this is a really useful feature.
Analogger (async logging service) handles this by requiring a client
to authenticate itself immediately after connecting. If there's any
demand for it, that's an easy thing to add to Swiftiply, too.
> to be some kind of gate keeper. That let's people use GPL code all
> they want, write commercial solutions, do their own coding style, and
> use any enhancers they feel like without having to be "blessed".
EM's license is actually the same as Ruby's license.
> Another point I'd like to make is there's some great work coming from
> the virtual machine camp. I'm not going to try using EventMachine
> stuff until I see how well or poorly Mongrel does on some of these new
> VMs. I'm hoping that the JRuby and Rubinius folks just fix threads,
> IO, and GC once and for all and then everyone can live in a happy
> loving land without relying on tons of nasty C++ to fix things.
Agreed. The upcoming crop of vms have potential. I'm building apps
today, though, and jruby just isn't a viable option right now. The
RAM usage alone is a crippling factor.
The C++ issue is a red herring. Factor the comments out of the code,
and it's not particularly large. Somewhat larger than the C code in
Mongrel, but not out of line for the work that it does, and it is a
mature, stable body of code in use in a variety of places for a lot
more applications than just HTTP traffic, on Solaris, Windows, OSX,
and Linux (at least).
All of that aside, though, the central thing for me with regard to
Mongrel is that since I have chosen to support a patched Mongrel as a
mechanism for using Ruby frameworks with Swiftiply, and I have chosen
to release the evented_mongrel, my intention with those two pieces of
the package is for them to be as transparent as possible to any
Mongrel handlers. They should just work. If they don't, I have bugs
to fix. Swiftiply and Mongrel are not married to each other, though.
Mongrel is just the one of the first of the supported platforms, and
the evented_mongrel is a nice extra component that we get basically
for free out of the deal.
I have setup a mailing list to use for discussion of anything specific
to Swiftiply. It is swiftiply-users at rubyforge.org and can be reached
Questions that are specific to Swiftiply or Swiftiply's Mongrel
support are better off over there, I think. I don't want to pollute
Zed's list here with things that aren't really about Mongrel itself.
I hope this clears up some misimpressions that people may have.
More information about the Mongrel-users