| Date | Commit message (Collapse) |
|---|
|
IO::Handle->new_from_fd has existed since at least 1996,
so it should be safe to depend on at this point.
|
|
Listening on Unix domain sockets can be convenient for running
behind reverse proxies, avoiding port conflicts, limiting access,
or avoiding the overhead (if any) of TCP over loopback.
|
|
This allows us to share more code between daemons and avoids
having to make additional syscalls for preparing REMOTE_HOST
and REMOTE_PORT in the PSGI env in -httpd.
This will also make supporting HTTP (and NNTP) over Unix sockets
easier in a future commit.
|
|
We've distilled the daemon code into one public function ("run"),
so avoid polluting the main namespace and just have users
prefix with the full package name for this rarely-used class.
|
|
For error messages intended to show user error (e.g. giving
invalid options), we add a newline ("\n") at the end to
polluting the output with location information.
However, for diagnosing non-user-triggered errors, we should
show the location of where the error occured.
|
|
This means we always load the PSGI server code early for
-httpd. This may make things less compatible with existing
PSGI/Plack apps, but we prioritize our httpd for the uses
of public-inbox itself, first.
And any existing PSGI/Plack app which wants to may adapt
themselves to being preload-friendly.
|
|
Writing a read-only IMAP server isn't out-of-scope, either,
but I've never studiied the IMAP protocol, much, unlike HTTP/1.x
or even NNTP.
|
|
Users may log output to a pipe, so ensure these outputs are
unbuffered in userspace and go to the operating system ASAP
for other processes to pick up.
|
|
When using user-switching in a single process, we must be
careful to not inadvertantly create new Msgmap sqlite3 files.
We must also ensure we set proper permissions on any files
we create.
Additionally, our refactoring was broken as we failed to
actually daemonize or preserve the parent FD in a worker
process.
Finally, default to one worker process since our code may
be fatally broken and it's nice to be able to scale to multiple
cores via SIGTTIN if needed.
|
|
We'll probably be supporting read-only IMAP, or maybe
we'll just implement a custom HTTP server so users can
manage/upgrade the same way as the nntpd while being
immune to slow clients.
|