rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / Atom feed
From: "Matthias Wächter" <matthias@waechter.wiz.at>
To: rack-devel@googlegroups.com
Subject: Re: Purpose of config.ru (regarding server options), #245
Date: Fri, 28 Oct 2011 23:01:56 +0200	[thread overview]
Message-ID: <4EAB1844.7060506@waechter.wiz.at> (raw)
In-Reply-To: <175A67F5-6EEB-46F4-A91A-967976D17869@gmail.com>

Hi James,

Thank you for the reply.

On 03.10.2011 01:20, James Tucker wrote:
> I understand what you want, but I do not want to maintain it.

Okay, let’s try it once more. I am really sorry for my initial pull request which might have caused 
your dislike of the patch as it included patches for another feature. I am really willing to enhance 
my git skills, so bear with me.

The actual change is simple and I think that you won’t have any trouble maintaining it. Remember, 
it’s coming with tests! :) I haven’t filed a new pull request, so please review the two commits I 
made on my branch, based on the latest rack/master branch.

https://github.com/typingArtist/rack/commit/a10b227c32c061fb18e42204bb6da07e237c80ad
https://github.com/typingArtist/rack/commit/0fd5b873de2096bb1b9e83e6f41fb5ed62ea8632

The changes do two things (not counting the changes for the test). First, I changed the eval() to 
not just return the app object – reduced from the Rack::Builder object via #to_app – but the full 
Rack::Builder object. As a side effect, this reduces the amount of code that runs within eval(). It 
allows to get the Builder object’s options to be returned and merged with the options given on the 
command line and on the special comment line. Second, I added the function which allows 
setting/adding options and retrieving them once the Builder object creation is done.

>> It
>> • defines which server technology to use (if there are multiple to choose from or if I want a specific solution),
>
> This is not an intended feature of config.ru. If you add a shebang with arguments, that will only work on *some* platforms. Not all exec*(2) implementations support arguments. This approach is not portable.

Nonono. I refer to the comment line starting as "#\" (yes, a backslash) which carries options – 
parsing these options is actually the first thing done in parse_file() after reading the .ru file. 
My patch is all about removing the need to use this #\ special comment line and allow Ruby 
constructs to be used instead.

>> • configures the used server, and
> There is no portable way to do this from inside config.ru.

Portable in which sense?

If I want to use rackup, I can use the #\ line or a whole lot of command line options to choose and 
configure the server. Why not allow those users to make those settings in a more Ruby-ish way?

>> • defines which application and possible middleware to load.
> This is all that config.ru is supposed to do.

Ouch. Then please remove rackup from rack.

> You should be able to run rackup(1) with a different -s flag and the config.ru will work …

As long as only portable options are entered to config.ru, the -s flag will work, certainly. At the 
moment, mongrel2 is special as it requires more and different options than a standard 
webrick/mongrel/thin server, i.e. just a port to run from.

> (furthermore, if the user executes rackup(1) directly, then the shebang is entirely ignored)

No, as said above, I am not referring to the standard shebang line but the one with the backslash.

> . Your proposal would lead to config.ru files that are not portable in this manner.

Yes and very much no. Users who want to use rackup and who want to setup their servers inside 
config.ru and know the limitations of the #\ line can do that already, but it comes at the price of 
having only one such line, special string escaping and just supporting strings. My patch allows for 
a much more elegant way of specifying these options within config.ru’s Ruby part, for those who want 
to use this feature – maybe it will lead to rackup being much more than an example binary in the future?

– Matthias

  parent reply	other threads:[~2011-10-28 21:02 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
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 [this message]
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=4EAB1844.7060506@waechter.wiz.at \
    --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).