various doc updates ahead of 1.5.0

[public-inbox.git] / TODO

diff --git a/TODO b/TODO
index 611d623a9b1be1ad2b534190f0cb94ebcf2f7d29..16de36bf200685ed8e59ede350966e9976b1682b 100644 (file)
--- a/TODO
+++ b/TODO
@@ -17,7 +17,7 @@ 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
@@ -42,6 +42,7 @@ 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
 
@@ -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,7 +104,7 @@ 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