| Date | Commit message (Collapse) |
|---|
|
Otherwise folks won't get downloadable mboxes
|
|
We may not support this after all, CGI.pm is already
legacy-enough and far more powerful.
|
|
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.
|
|
This is hopefully less ambiguous, as the word "count" confused
me, too.
|
|
These are not necessary, anymore
|
|
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.
|
|
Since mbox is usually downloaded, support fetching infinitely large
responses via streaming.
|
|
Some folks may not want to download and install Perl code like
ssoma, so allow downloading an mbox containing the entire
thread.
|
|
It's a bit disconcerting to jump to the authorship line.
|
|
This also avoids incorrectly incrementing $part_nr when
we skip a part due to bad Content-Type.
|
|
Oops!
|
|
We need proper ordering of References to thread messages
correctly. We would lose this order if we load the terms
from the database, so set it directly document data.
Do not bother with a separate In-Reply-To, since Mail::Thread
just merges the IRT into References. This bumps our schema
version once again.
|
|
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...
|
|
|
|
We may not be using subject_path after all.
|
|
Oops
|
|
Threading in Xapian is mostly supported by now; so start
documenting things.
|
|
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...
|
|
This should allow us to sync the index to a temporary head
to update the Xapian index before we update the real HEAD
index.
|
|
This hopefully reduces clicking. We may drop folding entirely
since we can use Xapian to make searching easier.
|
|
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.
|
|
In "index: simplify main landing page if search-enabled",
subject normalization went a little farther to drop trailing
'.' characters, so we will need to re-index.
|
|
We want to minimize the time any large objects or strings
are referenced. We can do threading entirely from the
mini_mime-generated messages and lazilly load full messages
when rendering the display.
|
|
We do not need ghost messages in any of our thread views
|
|
Email::MIME should handle everything for us and make things
work nicely with Xapian (assuming I understand how encoding
works in Perl).
While we're at it, reduce temporary strings and arrays by
using destructive operations and clobbering parts as we
iterate through them.
|
|
We can display /t/$MESSAGE_ID.html easily with a Xapian search
index, so rely on it instead of trying to display messages inline.
|
|
It is wrong HTML to have <a> tags nested due to auto-linkification.
|
|
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.
|
|
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.
|
|
Sometimes we have filter bugs and let HTML slip through...
|
|
We must not prematurely indent if we have no message header to
display.
|
|
Noticed by tidy
|
|
I often forget how to use this myself :x
|
|
Yay for monkey patching!
ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795913
ref: https://rt.cpan.org/Ticket/Display.html?id=106498
|
|
The following two commits affect indexing behavior, so
change the schema version to avoid compatibility problems
or missing messages:
search: common Subject: normalization for Re: prefixes
search: avoid creating ghosts for circular References
|
|
This makes it easier to reconfigure for non-English users
|
|
Drop German ("Aw:") support since it's non-standard and
is not supported by Mail::Thread and non-English prefixes
are more likely to conflict with prefixes used in Free Software
development where ("subsection:") prefixes are common and English is the
common language.
Anyways we don't filter "Vs: " (Finnish) or "Sv: "
(Norwegian, Swedish, Danish, Icelandic), either.
ref:
https://en.wikipedia.org/wiki/RE_(e-mail)#Abbreviations_in_other_languages
|
|
Some mail software incorrectly creates circular references
and causes us to create ghosts before the actual mail doc
is created.
|
|
Avoid compiling a weird and potentially fragile regexp every
time and use the same logic as our search module to dedupe
References.
|
|
This is merely for display, so on the off chance somebody does
send a 40-byte MID with nothing but hexadecimal characters,
the worst that could happen is we repeat an anchor name in the
rendered HTML. This has no impact on git archival or Xapian
indexing.
|
|
There's no need to make a transaction for each message when doing
incremental indexing against a git repository. While we're at it,
simplify the interface for callers, too and do not auto-create
the Xapian database if it was not explicitly enabled.
|
|
We'll ignore errors, for now, but should eventually warn or
log. And yes, this is a dirty, dirty hack but we'll fix this
ASAP tomorrow.
|
|
Valid URLs do not make valid anchor ids.
|
|
commit 0fea7793b22efd2596983283947ee43687e0cfac
("mid: compress Message-IDs with '%' in them")
requires re-indexing of repositories with '%' in Message-IDs :<
|
|
Some HTTP servers (apache2 2.2.22-13+deb7u5) on my system
apparently do not handle "%25" correctly. I'm not yet sure if
it's something weird with my rewrite rules or what....
|
|
Otherwise we'll be wasting space in our index for long
subjects.
|
|
We can rely on reference counting to lower memory usage for
big messages.
|
|
No need to waste bandwidth, here
|