Feature Req: Include Pipe

[Jonathan Dance]

> Of course, you could also do it your way and have your script read from
> a database, but I think simply having database support is more direct.

Obviously you already know my viewpoint, but here's a 5 line PHP
script to pull your configurations from a database - I chose PHP here
simply because of how easy it is to gain quick access to the database
(that, and I know PHP). This is assuming you were putting entire nginx
configs in the database:

#!/usr/bin/php
<?
mysql_connect(...);  // your database config here
$sth = mysql_query("SELECT body FROM configurations");
while($row = mysql_fetch_array($sth)) {
  echo $row[0] . "\n";
}
?>

If you were aiming to just put, say, vhosts, docroots, and some
particular settings in the database, you could put a lot more of the
configuration output in the script above, or you could have your front
end generate the configuration and put that in the database.

> ... though you might as well just write out a config
> file instead of wedging pipe support in.

You're right, I could use another script to generate my configs and
put those somewhere that would get included (e.g. in my glob
directory), and I think that's what I will do for now. I still support
pipe support though, it was useful when I was using lighttpd. :)

> Piped logs would be more
> convenient than using signals to rotate, though.

Being able to pipe logs is a great feature, one I have used in the
past. I've never used a fifo, but could you use a fifo to accomplish a
similar result? Just like pipes in configuration, it all depends on
how much you want nginx to do versus the OS/server admin/etc. It's a
fine line, no doubt.

( ... self.rtfm fifo ... )

Seems like it would work, but you would need to make sure your process
is opening the FIFO before nginx tries to open it, else nginx will
block trying to open the fifo, etc etc. Obviously, the advantage to
having it in nginx would be that it would manage all of this for you.

JD