Date | Commit message (Collapse) |
|
"bugs" might confuse and limit the discussion, so "meta" it is!
|
|
These probably make sense even though we do not handle
delivery ourselves. It can aid in searching/filtering/tagging
of messages.
|
|
This may be useful for generating List-Id headers and HTML pages.
|
|
We do not have all messages in the top-level index
(and we need to adjust the test while we're at it).
|
|
It is common to type upper-level URLs without the slash,
redirect users to the correct page for usability.
|
|
Not sure what I was thinking...
|
|
MIDs may have strange characters in them, so we need to handle
escaping/unescaping properly to avoid broken links or worse.
|
|
This might make it easier to go to non-CGI things.
|
|
We may have something like /foo.cgi/m/$MID.html in there.
|
|
This makes it easier to configure for systems which
determine a script is a CGI script based on suffix.
|
|
We may promote this to be a real script, since public-inbox-mda
is idempotent.
|
|
Message-IDs could have embedded '<' and '>'
|
|
This makes it possible to gradually migrate to new address in case
of list name changes, and is one step closer to operating in
"stealth hijack mode" :)
|
|
This is essential for integrating into my inotify-based
spam training setup.
|
|
Laziness \o/
(Then impatience and hubris :)
|
|
I often forget the subtleties of Perl regexps and newlines,
so I suspect others do, too. Use explicit capture so it's
more familiar to users of non-Perl regexps.
|
|
These need better tests and verification, but it's something
for now.
|
|
Code should be consistent with the design docs
(and we will need better tests).
|
|
Hopefully it's slightly easier-to-follow this way.
|
|
This prevents ambiguity when switching URLs between static
file servers and CGI.
The /$LISTNAME/index.html URL appearing in the wild is inevitable
because of our static file server support. Worst yet, there's
no easy/consistent way to get all installations detect and 301
them to the shorter /$LISTNAME/. So we make the CGI support
/$LISTNAME/index.html.
The downside of this is the potential duplicate entry in all caches.
|
|
Hopefully this forces us to generate valid UTF-8 data.
|
|
We may occasionally encounter horrid HTML which lynx cannot
handle, so improve error reporting.
|
|
We need it for converting HTML, unfortunately.
|
|
While we're at it, sort Makefile.PL and add a note to
update INSTALL, too.
|
|
This is essential when telling people to use something like:
curl $URL | git am
|
|
We'll probably support these so they're easier-to-type and share.
|
|
Remove the specified /all.html while we're at it, we only have
/all.atom.xml because it's convenient for feed readers.
|
|
The feed itself already specifies it in XML, and we risk confusing
clients if XML::Atom::SimpleFeed changes in the future. This also
increases consistency for CGI vs static-file serving.
|
|
We'll be reusing more validation logic for per-message and
per-thread pages.
|
|
Message-IDs are extremely long already, so try to keep them short here.
|
|
We did not test as well as we should have.
|
|
While we're at it, write some quick tests.
|
|
This can make it easy to query via "git log --author=..."
without extracting each message.
|
|
We will be using it when setting GIT_COMMITTER_NAME
|
|
For practical purposes, Message-IDs are unique and duplicates
do not appear unless client software is broken.
|
|
These tests were designed to run in parallel.
|
|
Hopefully a little easier to find for clients and not admins running
servers. While we're at it, expand design_notes.
|
|
Using JWZ threading might work decently for this.
Haven't checked in lynx, yet.
|
|
We should reject values which are too short to be useful or sane.
|
|
Composers may screw up and leave the subject out, so
reject those messages.
|
|
We will need it for HTML indices, too.
|
|
Things to keep in mind when working on this.
|
|
Trying my best to not forget things I wrote this years ago.
|
|
Most notably, the INSTALL is geared towards potential server admins,
whereas the README is also for interested "drive-by" readers.
|
|
We do not need to use CGI::Util internals here.
|
|
This should make it easier to support non-CGI uses,
as well as making it easier to generate static sites.
|
|
Passing a giant argument list is to error prone and
hard-to-document.
|
|
We serve the short, abridge-quote version by default since
it is (unfortunately) common practice to over-quote on mailing lists.
|
|
This wording is probably clearer to everyone, and also used by at
least one other mailing list WWW interface.
|
|
Avoid adding extraneous whitespace in HTML content, as it
increases bandwidth usage of network, disk and memory.
|