| Date | Commit message (Collapse) |
|---|
|
This hopefully makes it easy to perform queries to display
an entire thread. Raise the limit in the threaded view to
display more results and hopefully improve the output of
thread display.
|
|
In the future, it should be possible to use this:
git ls-files | UPDATE_COPYRIGHT_HOLDER='all contributors' \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
xargs /path/to/gnulib/build-aux/update-copyright
|
|
In case a URL gets truncated (as is common with long URLs),
we can rely on Xapian for partial matches and bring the user
to their destination.
|
|
This hopefully makes it easier to find things without resorting
to proprietary external services.
|
|
Omitting a slash should not be fatal if unambiguous. Add
fallbacks so users who expect a directory structure-like
experience can have it at the cost of one extra HTTP
request/response pair.
This matches behavior of static sites.
|
|
We do not want to get legacy URLs swallowed up by our workaround
for weird and wonky servers that attempt to unescape PATH_INFO
before the app sees it.
|
|
Unfortunately, some HTTP servers will try to be clever
with %2F and escape it to '/', making life difficult for
us. Fortunately, not many Message-IDs have slashes in
them.
|
|
Provide a fallback for legacy SHA-1 messages, but do not
advertise shorter URLs anymore for data portability concerns.
This fixes a regression introduced in
commit 81a9c1b476987d845b340ab9013d26cf4487cb9a
("search: disable Message-ID compression in Xapian")
which ended up breaking thread-related endpoints for
large Message-IDs, as lookups on the SHA-1 message no longer
worked.
|
|
Currently, this looks at other public-inbox configurations
served in the same process. In the future, it will generate
links to other Message-ID lookup endpoints.
|
|
For still-active threads, it will likely be easier to follow
them chronologically, especially if we have links to parent
messages.
|
|
This allows common /m/ links to be used without a prefix,
saving 2 precious bytes for permalinks and raw messages.
Old URLs continue to redirect.
|
|
The MIME type entry for Atom feed relies on "atom",
so allow properly-configured static file servers to serve
it with the correct Content-Type header.
|
|
No need for 'x' modifier to span more lines, though
|
|
This allows users to subscribe to only a single thread
with their feed reader without subscribing to the rest of
the thread.
Update our endpoint notes while we're at it.
|
|
It fails the syntax check if a user does not have
~/.public-inbox/config setup. Anyways we can safely
use ||= on a global since we do not support threads.
|
|
Perl does not currently optimize for this.
ref (from p5p):
http://mid.gmane.org/D5C27970-9176-4C7A-8B99-7D78360E67A2@pobox.com
|
|
We should not break existing URLs. Redirect them to
the newer, less-ambiguous URLs to improve cache hit
ratios.
|
|
These URLs are preferable in case somebody decides to get cute and
use a suffix we would've used to prevent others from linking to
their message. The common /m/$MESSAGE_ID/ URLs are now 4 characters
shorter so may fit better on terminals.
|
|
We will prefer URLs without suffixes for now to avoid ambiguity
in case a Message-ID ends with ".html", ".txt", ".mbox.gz" or
any other suffix we may use.
Static file compatibility is preserved by using a trailing slash
as most servers can/will fall back to an index.html file in this
case.
For raw text files, we will follow gmane's lead with "/raw"
|
|
Less scrolling is more efficient.
|
|
Less code is easier-to-manage, although we make a few extra
hash insertions now.
|
|
Using hash means we no longer have to document and remember what
every field does. The original array form was insane premature
optimization and crazy. Who wrote that? Oh wait, I was on
drugs :<
|
|
This improves compatibility and allows individual messages
to be concatenated into an existing mbox without further
modifications. "git format-patch" does something similar
(but does not do "From " line escaping(!))
|
|
Some folks may want to view the mbox inline as a string of raw text,
when guessing URLs. Let them do this...
|
|
We will attempt to generate Atom feeds "by hand" as the
XML::Atom::SimpleFeed API does not support streaming output.
Since email is large and servers are small, this should prevent
wasting memory when we generate larger feeds.
Of course, we hope clients use SAX parsers capable of handling
large streams without slurping.
|
|
Hopefully this saves us some memory with CoW on *nix.
|
|
This should allow progressive rendering on the client and reduce
memory usage on the server. Unfortunately XML::Atom::SimpleFeed
does not yet support streaming, so we may not use it in the
future.
|
|
Mboxes may be huge, so only support downloading gzipped mboxes
to save bandwidth and to get free checksumming.
Streaming output means we should not be wasting too much memory
on this unless the chosen server sucks.
|
|
Some folks may not want to download and install Perl code like
ssoma, so allow downloading an mbox containing the entire
thread.
|
|
We may not be using subject_path after all.
|
|
Oops
|
|
Table rendering in lynx is crap compared to w3m and links.
However, we still use it for filtering HTML since the renderer
is otherwise nice...
|
|
Some people (e.g. myself :p) may try to guess URLs and hit a
404. Redirect to the /m/ version.
Note: we prefer to redirect to canonical URLs to improve
caching.
|
|
No need to create a new hash when we can reuse the existing one
more.
|
|
This parameter hasn't been used since
commit 5adf8d639e9b5abd4cbac975d70ddc0fb76541fc
("feed: dead code elimination around dropped endpoints")
|
|
/t/ always falls back to subject path searching anyways,
so there's little lost besides perhaps more readable URLs.
Unfortunately people still use non-compliant mail clients which fail
to set In-Reply-To or References headers :<
|
|
More to come later.
|
|
Quick-and-dirty wiring up of to Subject: paths.
This may prove more memorizable and easier-to-share than
/t/$MESSAGE_ID.html links, but less strict.
This changes our schema version to 1, since we now
use lower-case subject paths.
|
|
This should bring up nearly the entire thread a given
Message-ID is linked to.
|
|
This can be used to quickly scan for replies in a message without
displaying an entire thread.
|
|
Some Message-IDs are crazy long, so support SHA-1s for them
instead. This allows shorter URLs to be generated and are
less likely
However, we'll still favor short Message-IDs whenever possible.
|
|
It's important to keep HTML source readable to folks who prefer
to read raw HTML. This should improve readability of the HTML
source by keeping line length in check without wasting bytes.
|
|
This looks nicer to me (totally subjective and open to bikeshedding
:P)
|
|
Oops, this was an oversight.
|
|
URLs may be long, so give each its own line.
|
|
Some advertising is necessary.
|
|
These views are not OO, so the "as_" prefix makes little sense
and "as_html" conflicts with Hval, which is OO.
|
|
This should reduce data copies and memory usage, according
to Email::Simple documentation.
|
|
Thanks to Ask for the patch in
https://rt.cpan.org/Public/Bug/Display.html?id=22817
|
|
This should allow us to more-easily test with Plack.
|