| Date | Commit message (Collapse) |
|---|
|
Email::Address::name never fails assuming it was able to parse
anything.
|
|
public-inbox git repositories require a "HEAD" ref to
function correctly anyways.
|
|
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.
|
|
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.
|
|
Oops!
|
|
This is for consistency with ssoma. I doubt it makes
a difference in practice, but in case somebody decides
any of the Message-ID-containing headers should have
strange characters, we'll decode and attempt to thread
them. This isn't an attack vector, just a way to
make messages thread improperly which is pointless...
|
|
Add some spacing between topics to improve readability when
scanning or in case a subject gets too long.
The title and Atom feed may not be highly-visible otherwise.
While we're at it, use the proper "Atom feed" terminology since
some folks may not understand just what "atom" means.
|
|
We can display /t/$MESSAGE_ID.html easily with a Xapian search
index, so rely on it instead of trying to display messages inline.
|
|
This is more space efficient since we don't need to place padding
bytes in front of every line. While this unfortunately does not
render well on lynx; w3m, links, elinks can all render tables
sanely.
Tables are also superior for long lines which require wrapping
inside <pre> containers.
|
|
We don't need share duplicate logic across both files.
|
|
We'll be making the index smarter for people with search
support enabled. Otherwise, it'll be chronological and
a bit dumb. At least it'll use less memory.
|
|
We can rely on reference counting to lower memory usage for
big messages.
|
|
No need to waste bandwidth, here
|
|
No need to create a new hash when we can reuse the existing one
more.
|
|
/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 :<
|
|
We no longer do "smart" time displays as of
commit ea0e8649f90d1fd0850a41c0ca16642faadf4f14
("view: simplify timestamp generation").
In retrospect, that commit also made us more cache-friendly, too.
|
|
We'll be sharing the same threading, so it makes sense to sort
replies using the same code and message headers without repeating
ourselves.
This also standardizes on sorting on X-PI-TS (Unix epoch in seconds)
instead over using X-PI-Date differently in two different places
|
|
We'll be using this in the future for displaying per-thread
views.
|
|
This avoids some runtime penalties associated with recompiling
a regexp based on a constant local variable.
|
|
Oops, noticed by manual inspection. One day we'll run tidy in tests
to validate.
|
|
This helps readers jump around more quickly when there are
large messages.
|
|
This allows us to more-easily group and pass parameters.
|
|
This should allow us to reference discussions more easily.
|
|
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.
|
|
Avoid redundant subroutine calls as their costs tend to add up.
|
|
Only root messages should be sorted in reverse chronological order,
child messages should be chronological. This gives precedence to
_topics_, but also for initial replies.
This improves readability when several messages appear at the same
nesting level, and helps git patch series' appear correctly as:
[PATCH 0/3] ...
[PATCH 1/3] ...
[PATCH 2/3] ...
[PATCH 3/3] ...
Instead of (what it was previously):
[PATCH 0/3] ...
[PATCH 3/3] ...
[PATCH 2/3] ...
[PATCH 1/3] ...
|
|
Sometimes we get spam and need to delete messages,
we must prevent errors on missing messages from propagating.
|
|
This will make it easier to bookmark an index page with threading
context.
|
|
This reduces the need for page reloads in common cases and should
improve reading speed so users do not need to open many browser
tabs. This will hopefully increase an encourage readership.
The downside of this are increased server processing overhead and
easier address scraping by spam bots.
|
|
This is probably useful information for folks browsing via web
interface. It'll probably make more sense if we show the entire
body in the threaded display, though.
|
|
Horizontal scrolling is a usability problem for GUI browsers,
so help them avoid it. I love GUI users, really! :)
|
|
This should improve navigation as browsers may not make it
obvious there is an Atom feed.
|
|
Some advertising is necessary.
|
|
Screen space is precious, and we do not need it in the abbreviated
view.
|
|
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 prevents memory bloat in case we're serving many requests
with a large, diverse set of email addresses (potentially from
malicious spammers).
|
|
This should elimate all of our %ENV dependencies in the WWW portion
of our code.
|
|
We use --git-dir=... instead of $ENV{GIT_DIR} because ENV changes
do not propagate easily with mod_perl.
|
|
Implicit string conversion is more confusing.
|
|
Browsers know how to follow relative URLs, so we may generate
smaller HTML pages.
|
|
This is one less key stroke for somebody paging through the
list history.
|
|
This saves one round-trip request response so reduces latency over
slow links. The redirect only exists for convenience and isn't 100%
reliable in case the Message-ID terminates with a .(html|txt)
suffix.
|
|
public-inbox is for discussion, so top-level posts do not get
special treatment.
|
|
This is unfortunately needed for scalability to long histories.
The design of git requires it to traverse full history to walk
forward in time, since commits can only record past history.
Instead, replace "prev" with a "head" link to zip us back to
the most recent page. Users who wish to go backwards can use
browser history, which should always work on our old-fashioned
HTML pages.
|
|
This is more correct, although it costs us 4 bytes.
|
|
This might be slightly cleaner, though generating the base URL
now has an ugly condition in it.
|
|
This should work in most browsers, lets find out!
|
|
For each feed element, we'll just use the link since there's
currently no suitable URN.
|