Giving users the ability to edit their own Apache config file isn't
enough to let them set arbitrary FastCGI/proxy/whatever options: they
also have to be able to restart the master Apache dispatcher in order
to make it reload the config file. Even barring that, (using some
ad-hoc FAM or cron-driven auto-restart model) there are all kinds of
things you can do inside an Apache config that just aren't appropriate
for a shared-hosting level of privileges, such as redirecting other
people's vhost traffic to your own service, running an open proxy,
etc.

There's been some discussion on the mousehole-scripters list recently
about how nice it would be to have a simple "HTTP accelerator" module
for Ruby -- i.e., fast C code which took care of low-level connection
handling, header parsing and generation, and static content serving,
which then passed dynamic code up to the Ruby tier. Alternately, a
simple event-driven, rather than blocking-thread-based, HTTP server
written in pure Ruby would likely be a significant step up from
WEBrick.

Having WEBrick in the standard library is certainly a Good Thing --
I've prototyped and demo-ed lots of apps (Rails and otherwise) using
it. However, there is a glaring hole between the "enterprise" level of
service, ala Apache/FCGI/lighttpd/et. al., and the
one-client-at-a-time model that WEBrick supports.

Perhaps we've got a target for the next PDX.rb group hackfest?

-Lennon
_______________________________________________
PDXRuby mailing list
[email protected]
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby

Reply via email to