rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / Atom feed
From: coolesting <coolesting@gmail.com>
To: rack-devel@googlegroups.com
Subject: Re: Purpose of config.ru (regarding server options), #245
Date: Sun, 2 Oct 2011 19:46:42 +0800	[thread overview]
Message-ID: <CAFrb6rSQkRvGZOixbavB6+-GMgh1Z4+yBi9n9CMxs_rPQ=o_JA@mail.gmail.com> (raw)
In-Reply-To: <4E884A1D.2080102@waechter.wiz.at>

I think the config.ru is a interface for rack and let the rack to do
something what we want .

Whatever we do anything with the config.ru, we need to based on the
rack interface provided,  that is why we create a file config.ru for
rackup to start up the variety of web server, just my opinion.

2011/10/2 Matthias Wächter <matthias@waechter.wiz.at>:
> Hi,
>
> Recently, I forked rack and created a feature
> [https://github.com/rack/rack/pull/245] that allows one to specify web
> server options as commands within config.ru, not only on the rackup command
> line or the comment line (#\) within config.ru. The need for this arises
> from new web server technologies like the ones typically used for Mongrel2
> which need significantly more setup information than a simple Webrick or
> (legacy) Mongrel server.
>
> Mongrel2 typically exchanges its web server requests and responses through
> *two* sockets, based on ZeroMQ, and these sockets can finally be Unix Domain
> Sockets which don’t waste the TCP socket address space. OTOH, in
> well-structured environments those IPC sockets need longer path names than a
> simple TCP port number, additionally it might be beneficial to use Ruby
> techniques to build up the IN and OUT IPC sockets based on some common
> pattern. Furthermore, Mongrel2 relies on a uuid setting for identifying
> sessions.
>
> Setting all those options on the command line to a standalone rackup
> execution defeats its purpose, and setting them within the config.ru file
> inside the tiny littly comment line is ugly and cannot make use of Ruby
> constructs at all. So the idea was to let the newly created Rack::Builder
> object handle those options and hand it over to the calling process.
>
> My change request, together with the necessary code and test changes, was
> rejected and closed right away by James with the comment
>
>> config.ru is supposed to be portable and not bound to a particular server.
>
> I wonder whether it’s James who doesn’t understand what I want, or whether
> it’s me who doesn’t understand what config.ru is supposed to be. I thought
> it is meant as a server configuration file: It
>
> • defines which server technology to use (if there are multiple to choose
> from or if I want a specific solution),
> • configures the used server, and
> • defines which application and possible middleware to load.
>
> The goal, as far as I got it, is to have the application and its setup bound
> together in a single configuration file, called config.ru. Sadly, the
> current syntax is only optimized for defining the application; the first two
> items on the list are handled via a clumsy comment line that gets longer the
> more options the web server requires for configuration.
>
> So, can someone enlighten me, what’s the purpose of config.ru? Isn’t it
> supposed to carry the configuration for the web server as well?  Is it a bad
> idea to let Rack::Builder collect all these options within the config.ru
> body instead of the comment line?
>
> – Matthias
>

  reply	other threads:[~2011-10-02 11:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-02 11:25 Purpose of config.ru (regarding server options), #245 Matthias Wächter
2011-10-02 11:46 ` coolesting [this message]
2011-10-02 23:20 ` James Tucker
2011-10-03  8:52   ` Christian Neukirchen
2011-10-29  1:06     ` Matthias Wächter
2011-10-28 21:01   ` Matthias Wächter
2011-12-21  9:08     ` Matthias Wächter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://groups.google.com/group/rack-devel

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFrb6rSQkRvGZOixbavB6+-GMgh1Z4+yBi9n9CMxs_rPQ=o_JA@mail.gmail.com' \
    --to=rack-devel@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).