
Mongrel2 1.0 released. - ryan-allen
http://sheddingbikes.com/posts/1283412933.html
======
bnoordhuis
I've put up a GH repository of mongrel2 with its dependencies included.
Compiling and installing should be as simple as typing:

    
    
      make all install PREFIX=$HOME/opt/mongrel2
    

<http://github.com/bnoordhuis/mongrel2>

~~~
nailer
First, thanks!

From your commit log:

> Disable target install-py for now, it requires sudo.

Agreed: re: disabling app that needs root unnecessarily. I don't want anything
fucking with my OS python.

Have you considered having it simply call pip instead, so it installs to the
current virtualenv?

~~~
zedshaw
We should revist this. It's mostly for convenience since lots of people just
put the m2sh stuff wherever everything else goes. Problem is that screws up
virtualenv folks.

Any ideas on it other than disabling?

~~~
baq
everything else goes into virtualenvs or user bin/pythonpath; python stuff is
unfortunately too fragile to put everything in one place.

~~~
nailer
It's not so much about Python being fragile, it's more that the OS - Linux in
particular - uses Python itself, and modules can modify the behavior and break
it. (same things if you used Puppet to manage your configs and broke your OS
Ruby).

Keeping everything in one dir also makes deployment way simpler.

------
emehrkay
I am simply impressed at how much sh*t he gets done. I honestly want to be
more like him

~~~
jshen
you should probably spend less time here ;)

~~~
SkyMarshal
I actually think it's fine to spend time on HN, you just can't also spend tons
of time on tons of other sites as well.

Based on anecdotal evidence only, it seems the rate at which articles move up
and down the HN frontpage pretty much ensures you'll see everything that hits
the front page per day if you check HN twice - once in the morning and once in
the late afternoon or evening.

I don't think that's too much HN browsing to prevent you from being uber
productive, as long as you're not also browsing tons of other sites on the net
too.

~~~
jshen
or having discussions in the comments

------
arturadib
I've read the introduction and I still don't quite know what the fuss is all
about.

Perhaps some examples of its benefits right in the introduction?

~~~
steveklabnik
First of all, there's a fuss because it's written by zedshaw. Secondly,
zedshaw also authored mongrel, a well-known web server that many people have
taken the ragel-based parser from to build their own stuff. Third, everyone's
been talking about this whole 'sqlite as configuration' thing, which could be
awesome or horrible, the jury's still out. Finally, it's always interesting to
see new projects in 'solved' areas. How long has Apache been around? How well
is it tested? It obviously works, but could it be better? Zed's trying out new
ideas, has a crazy amount of test coverage, and is starting out fresh.

I haven't tried it yet. But it's certainly interesting.

~~~
jshen
what your'e saying is that there isn't yet a compelling reason for most people
to try it.

~~~
mikeryan
Sounds like there are a ton of compelling reasons to _try_ it.

~~~
jshen
As someone who runs multiple sites and who doesn't have a major problem with
apache, what here should compel me to try it?

Ragel parser? Um, why should I care if I'm not going to dig into the code
myself?

because zedshaw is so fucking awesome? Not a compelling reason to try a web
server to me, is it to you?

sqlite configuration? Maybe, but that's not super compelling to me at the
moment.

despite my sarcasm, my question is sincere. I'm curious how mongrel2 could be
an improvement over what is currently used, which for me is mostly apache

Any other reasons?

~~~
zedshaw
I'm a firm believer that if it ain't broke don't fix it. If you've got
multiple sites working with Apache and you know how to keep that going smooth,
then stick with that. Especially if you're doing small to medium sites in say
PHP. PHP and Apache are kind of the king and queen of the realm.

What Mongrel2 has over Apache is it's ability to run async jssockets, HTTP
long poll style work, and regular HTTP at the same time. If you hit an
application where you want to do some async socket type stuff, that's when you
should look at Mongrel2.

Of course, that's not all it does, but if you already love your Apache and
it's crazy config file format and weirdo 1995 style syntax, then Mongrel2's
only addition is the extra protocols.

~~~
jshen
thanks, that makes perfect sense. No, I don't love apache's crazy config file
format, but I don't update the config often and it's mostly copy and paste
when I need to add something new. It's rails with passenger which is pretty
easy.

I'll definitely check out the async stuff, that is compelling!

------
risotto
I saw a demo of Mongrel2, and it's really slick. Lots of new concepts to get
behind, which is both scary and exciting.

There's no way I can use it for anything remotely close to production but I
have some hobby ideas baking...

~~~
zedshaw
Thanks. Let me know what you do and shoot me bug reports on anything you find.

------
jallmann
According to the Mongrel2 Book
([http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-560005....](http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-560005.1.1)),
there is no pipelining of HTTP requests. Without testing anything for myself,
I'm really surprised at this; are the perf gains from pipelining really as
negligible as the book says they are?

~~~
points
That whole 'Note 8' sounds pretty stupid.

"In Mongrel2 we use a parser that rejects invalid requests from first basic
principles using technology that's 30 years old and backed by solid
mathematics."

The mind boggles... (Unless he's just being satirical here).

Personally, my advice to anyone thinking of using mongrel2 would be to write
your own webserver. You'll learn far more than you ever dreamt. If a webserver
isn't _that_ important to your success/failure, use a battle-worn webserver -
apache etc

~~~
lmz
Well, it is true. He's validating it with a grammar, not some adhoc parser
implementation.

~~~
points
Can you explain why 'validating it with grammar' is better than 'some adhoc
parser'?

IMHO a webserver is one of the things you want to be relaxed, laid back, and
basically not care if the client gets things wrong. Just serve up what they
look like they wanted.

~~~
zedshaw
As long as you don't get into the algorithms it's pretty simple.

A hand written http parser is kind of like writing a "white-list" of what the
server rejects. Since there's no algorithm backing it the only thing you can
do is list out all the things you can think of or have run into that is
"wrong".

Using a parser (well lexer really) like Ragel I can make something that's
relaxed, but it's more of a white-list of what it _accepts_. The algorithm
explictily says this particular set of characters in this grammar is all that
I'll answer to.

If you then write the grammar so that it handles 99% of the requests you run
into in the wild, you get the same relaxed quality as a hand written one, but
it explicitly drops the 1% that are invalid or usually hacks.

This is also the same parser that's power a large number of web servers in
multiple languages, so it's proven to work.

~~~
points
My mind is still boggling over how you make a simple HTTP request parser so
complex sounding.

~~~
shoover
Take a look at the Mongrel/Mongrel2 Ragel grammar and compare it to a hand-
written request parser. You might be surprised which is complex.

~~~
points
Yeah I just did. Mongrel2 looks overly complex. But then it is C...

------
ubercore
I'm missing the boat on how it's more language agnostic than other web servers
(I'm most familiar with Apache)?

EDIT: I see now that it's "language agnostic" based on using ZeroMQ to shuttle
request/responses between Mongrel2 and a language with a ZeroMQ library.
Sounds cool, but also makes me wonder exactly how that's different from
someone writing, say, mod_zeromq for Apache, and attaching handlers to ZeroMQ
in the same way Mongrel2 does? Am I missing something?

~~~
zedshaw
Apache's architecture is such that it's very bound to "files" and a strict
request/response message pattern. That makes things like long polling, async
sockets, and even streaming say ICY (check our mp3stream demo) really
difficult.

In Mongrel2 it's kind of like every thing's long poll or an async socket. That
let's you do a ton of very cool things you can't do easily in Apache or other
web servers. Sure you could hack them in, but it's a nightmare.

~~~
ubercore
I think I get it, thanks. Mongrel2 is better at being language agnostic, by
virtue of intentional design. Looking forward to trying it out!

------
slashclee
Congrats on the release, Zed!

~~~
zedshaw
Thanks man. Can't wait to get to the next level with it.

------
deweller
I believe the potential of Mongrel2 lies in real-time web applications.

Want to write a backend in PHP for a real-time chat? That is very difficult
with Apache and mod_php. With Mongrel2 and ZeroMQ, it is almost trivial.

Mongrel2's asynchronous pub/sub networking paradigm opens up possibilities for
real-time communication to browsers. When websockets get real, Mongrel2 may
very well be the way we all start using them.

Where Mongrel2 has some ground to cover is handling traditional server-
generated pages. Want to run an existing PHP application with a framework like
CodeIgniter? You can't do it from Mongrel2 without proxying to nginx or apache
(yet). Hopefully this is something that will come along in Mongrel2 v2.0.

------
agazso
I have an old idea regarding webservers: peer-to-peer file transfer. The
server would not store the file on disk, only the last transferred block in
memory. Rate control would be done at TCP level: while the block is not
transferred by the receiver, the server would not read again from the sender.

I have written several HTTP servers myself, and I know it's doable, but the
world does not need another webserver that only has this distinguishing
feature.

My question is if all of this can be done with Mongrel2?

------
limist
If you're not immediately grokking the significance of Mongrel2 (as I did
not), be sure to check out the documentation's Introduction:

<http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-40001>

The features sound cool and significantly evolved past current webservers. And
the documentation is extensive and so far, an enjoyable read - now _that's_
impressive. :)

------
oomkiller
So is this designed to replace apache/nginx, or should i throw it behind an
nginx upstream still and let nginx serve the files?

~~~
there
it can do either, but i think it's designed to do the former.

------
arnorhs
Sweet stuff. Arnor's got a new toy! Good job Zed.

------
michaelhalligan
Good work Zed!

------
grrrrr
I have no doubt that for what it is this is a well designed piece of software,
but, I'm gong to stick my neck out and say that purely for reasons of
scalability a web server written in Ruby just doesn't seem like a sensible
choice.

~~~
ErrantX
Twitter used to use Mongrel, but replaced it with Unicorn (uh, another Ruby
based server :))

<http://engineering.twitter.com/2010/03/unicorn-power.html>

~~~
nailer
Well they're using Scala in production now, so if they wanted to use Mongrel2
messaging, they probably can.

~~~
steveklabnik
They're using it for back end stuff, the front is still Ruby. To my
understanding.

