X-Git-Url: http://www.git.stargrave.org/?p=public-inbox.git;a=blobdiff_plain;f=TODO;h=16de36bf200685ed8e59ede350966e9976b1682b;hp=369fc56ed92b4bbb8c0ebdb1bf850a832d33f360;hb=cc5d9ec286f758de07b57087cfd537759b93dabe;hpb=93e56f66355e62f30cbc94b2e32e94c55849c878

diff --git a/TODO b/TODO
index 369fc56e..16de36bf 100644
--- a/TODO
+++ b/TODO
@@ -17,11 +17,11 @@ all need to be considered for everything we introduce)
   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.
 
@@ -42,12 +42,13 @@ all need to be considered for everything we introduce)
   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
 
@@ -75,9 +76,9 @@ all need to be considered for everything we introduce)
 * 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?)
@@ -103,17 +104,13 @@ all need to be considered for everything we introduce)
   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
 
 * imperfect scraper importers for obfuscated list archives
   (e.g. obfuscated Mailman stuff, Google Groups, etc...)
 
-* consider using HTTP::Date instead of Date::Parse, since we need the
-  former is capable of parsing RFC822-ish dates, used by Plack, and
-  the latter is missing from OpenBSD and maybe other distros.
-
 * improve performance and avoid head-of-line blocking on slow storage
 
 * share "git cat-file --batch" processes across inboxes to avoid
@@ -145,3 +142,5 @@ all need to be considered for everything we introduce)
 
 * figure out how search for messages with multiple Date: headers
   should work (some wacky examples out there...)
+
+* support UUCP addresses for legacy archives