| Date | Commit message (Collapse) |
|---|
|
Since we're advertising our address at meta@public-inbox.org,
we should advertise the archives, too.
|
|
Use the full URL of the inbox being mirrored to reduce ambiguity
(instead of just the inbox name).
Using asymmetric quotes (e.g `foo') improves readability for me
in that it's more obvious when a quote begins and ends. It also
lights up fewer pixels and reduces visual noise compared to
double-quotes.
We'll also reflow the `mainrepo' vs `inboxdir' comment slightly
to emphasize the word `instead'.
|
|
Save screen space and light up fewer pixels to reduce visual noise.
|
|
The `solver' feature is not very obvious, give potential
users a hint about it.
|
|
gzf_maybe always returns a GzipFilter object, even if it uses
CompressNoop. We can also use ->zflush instead of
->translate(undef) here for the final bit.
|
|
Z_FINISH is the default for Compress::Raw::Zlib::Deflate->flush,
anyways, so there's no reason to import it. And none of C::R::Z
is needed in WwwText now that gzf_maybe handles it all.
|
|
No point in streaming a tiny response via ->getline,
but we may stream to a gzipped buffer, later.
|
|
Most of our plain-text responses are config files
big enough to warrant compression.
|
|
The watchheader key supports only a single value. Supporting multiple
watchheader values was mentioned in discussion [1] of 8d3e3bd8 (doc:
explain publicinbox.<name>.watchheader, 2019-10-09), and it wasn't
clear if there was a need.
One scenario in which matching multiple headers would be convenient is
when someone wants to set up public-inbox archives for some small
projects but does _not_ want to run mailing lists for them, instead
allowing others to follow the project by any of the pull mechanisms.
Using a common underlying address, an address alias for each project
is configured via a third-party email provider, with messages for each
alias being exposed as a separate public-inbox archive. In this
setup, messages for an inbox cannot be selected by a List-ID header
but can be identified by the inbox's address in either the To or Cc
header.
To support such a use case, update the watchheader handling to
consider multiple values, accepting a message if it matches any value.
While selecting a message based on matching _any_ rather than _all_
values is motivated by the above scenario, it's worth noting that the
"any" behavior is consistent with how multiple listid config values
are handled.
[1] https://public-inbox.org/meta/20191010085118.r3amey4cayazfycb@dcvr/
|
|
Exposing altid dumps will help and ensure total reproducibility
of existing instances.
AFAIK, sqlite3(1) can't execute arbitrary code, so it's not
quite as fashionable as the "curl | bash" stuff the cool people
are doing, these days :P
|
|
And show contact info when there's no indexing, at all.
Installations where Xapian is too expensive can still support
threading since it only depends on SQLite, so we need to inform
users of what's available.
|
|
I didn't wait until September to do it, this year!
|
|
Since we support inboxes with multiple URLs and multiple
infourls to reduce reliance on SPOFs, we'll do the same with
cgit URLs.
|
|
inbox.$NAME.url is a common parameter and set by
public-inbox-init(1), so ensure we have lines for it and
emphasize it can be multi-value for .onion hidden services or
otherwise mirrored and available under multiple URLs.
|
|
This is now an array, so ensure it's shown properly in the
sample config, instead of "ARRAY(0xI8BADBEEF)" or similar.
Fixes: 1988d730c0088e8b "config: support multi-value inbox.*.*url"
|
|
We can pass arbitrary local variables via WWW $ctx, so
just pass that into the one-off _do_linkify sub which
already exists.
|
|
"mainrepo" ws a bad name and artifact from the early days when I
intended for there to be a "spamrepo" (now just the
ENV{PI_EMERGENCY} Maildir). With v2, "mainrepo" can be
especially confusing, since v2 needs at least two git
repositories (epoch + all.git) to function and we shouldn't
confuse users by having them point to a git repository for v2.
Much of our documentation already references "INBOX_DIR" for
command-line arguments, so use "inboxdir" as the
git-config(1)-friendly variant for that.
"mainrepo" remains supported indefinitely for compatibility.
Users may need to revert to old versions, or may be referring
to old documentation and must not be forced to change config
files to account for this change.
So if you're using "mainrepo" today, I do NOT recommend changing
it right away because other bugs can lurk.
Link: https://public-inbox.org/meta/874l0ice8v.fsf@alyssa.is/
|
|
We want to share this piece for potential mirror-ers just
like watchheader.
|
|
This returns a git-config(1)-compatible file to make it easier
to get started on mirroring an existing public-inbox. Omitting
the "raw" from the URL works, as well, but I'm not sure if
it's very useful.
|
|
|
|
We were relying on Danga::Socket using the "bytes" pragma,
previously. Nowadays, the "bytes" pragma is not recommended in
general, but bytes::length remains acceptable for getting the
byte-size of a scalar.
|
|
For user documentation regarding CSS; showing users the sample
CSS with comments is probably more helpful than having
standalone documentation on CSS classes.
|
|
Since we now support more CSS classes for coloring,
give this feature more visibility.
|
|
Hopefully this helps people familiarize themselves with
the source code.
|
|
Using update-copyrights from gnulib
While we're at it, use the SPDX identifier for AGPL-3.0+ to
ease mechanical processing.
|
|
This should give this feature some more visibility.
|
|
I originally envisioned wwwtext being more flexible and able to
serve arbitrary blobs; but at this point I consider it redundant
and public-inbox is not wiki software.
|
|
Support (and document) 'a:' after all, as "mairix -h" uses it,
so this should reduce the learning curve for mairix users.
|
|
Begin documenting some basic help functionality.
I may tweak the anchor names of the various HTML endpoints
to be more consistent with each other (old ones will be
supported for a short while), so I'm not documenting
those, for now.
This may become part of a builtin key-value store for
basic texts, but this probably shouldn't become a wiki
engine, either.
|