Date | Commit message (Collapse) |
|
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.
|
|
It's strictly not necessary anymore since
commit fa6168c56bdd1cece178b6b852a9b2cba6ce6ffb
("feed: message must exist in current HEAD to show up")
However it can still save us some unnecessary syscalls and
round-trips to the "git cat-file --batch" process, so it's probably
worth th cost of stuffing it in a hash.
|
|
We do not want recently-deleted spam showing up when looking
in old histories.
|
|
Hopefully this simplifies and corrects our usage of Perl encoding
APIs.
|
|
This helps us keep track of escaping which needs to be done
for various levels.
|
|
While we're at it, make sure strange characters are escaped properly
in Message-IDs. We'll need tests for all this behavior.
|
|
This needs to be cleaned up
|
|
Do not repeat ourselves, just use the same description file
gitweb uses to avoid surprising users.
|
|
We do not have much history in public-inbox meta, so do
not mislead users with strange navigation elements which
lead nowhere.
|
|
This is not a blog. All posts, whether replies or not,
carry equal weight.
|
|
Screen real-estate is valuable, and missing roots tend to
be false-positive matches (using Subject, not In-Reply-To
or References).
|
|
Just in case there is an error, this should be more explicit.
|
|
This shaves off nearly 100ms when my Core2Duo is clocked to 800Mhz
when rendering a full HTML index.
|
|
Git::cat_blob is a handy interface to read multiple emails
without incurring fork + exec overhead. Git.pm is GPLv2+,
not GPLv2-only, so we may link to it.
|
|
This allows WWW readers to slowly page through the entire history
of the mailing list.
|
|
This is hopefully the most user-friendly method.
|