https://public-inbox.org/meta/20160411034104.GA7817@dcvr.yhbt.net/
Perhaps make this depend solely the NNTP server and work as a proxy.
Meaning users can run this without needing a full copy of the
- archives in a git repository.
+ archives in git repositories.
* HTTP and NNTP proxy support. Allow us to be a frontend for
firewalled off (or Tor-exclusive) instances. The use case is
- for offering a publically accessible IP with a cheap VPS,
+ for offering a publicly accessible IP with a cheap VPS,
yet storing large amounts of data on computers without a
public IP behind a home Internet connection.
while retaining compatibility with old versions.
* Support more of RFC 3977 (NNTP)
+ Is there anything left for read-only support?
* Combined "super server" for NNTP/HTTP/POP3 to reduce memory overhead
* Configurable linkification for per-inbox shorthands:
"$gmane/123456" could be configured to expand to the
- appropriate link pointing to the gmane.org list archives,
+ appropriate link pointing to the gmane.io list archives,
likewise "[Bug #123456]" could be configured to expand to
point to some project's bug tracker at http://example.com/bug/123456
* linkify thread skeletons better
https://public-inbox.org/git/6E3699DEA672430CAEA6DEFEDE6918F4@PhilipOakley/
-* low-memory Email::MIME replacement: currently we generate many
- allocations/strings for headers we never look at and slurp
- entire message bodies into memory. GMime+Inline::C could work.
+* Further lower mail parser memory usage. We still slurp entire
+ message bodies into memory and incur 2-3x overhead on
+ multipart messages. Inline::C (and maybe gmime) could work.
* use REQUEST_URI properly for CGI / mod_perl2 compatibility
with Message-IDs which include '%' (done?)
Sometimes an indexing bug only affects a handful of messages,
so it's not worth the trouble of doing a full reindex.
-* code repository integration (with cgit, gitweb, etc...)
+* code repository integration (cgit: done, TODO: gitweb, etc...)
* migration path to v2 without breaking v1 "git fetch" cronjobs
* figure out how search for messages with multiple Date: headers
should work (some wacky examples out there...)
+
+* support UUCP addresses for legacy archives