nntp: inline CRLF in all response lines

[public-inbox.git] / TODO

diff --git a/TODO b/TODO
index 8e1f4eaf1298e00a1886cf393538f0046868e15e..7a27fdd2f716e80d1542c94a00662e42c5b90ba3 100644 (file)
--- a/TODO
+++ b/TODO
@@ -32,7 +32,7 @@ all need to be considered for everything we introduce)
   archive locations to avoid SPOF.
 
 * optional Cache::FastMmap support so production deployments won't
   archive locations to avoid SPOF.
 
 * optional Cache::FastMmap support so production deployments won't

-  need Varnish (Varnish doesn't protect NNTP or IMAP, either)
+  need Varnish (Varnish doesn't protect NNTP nor IMAP, either)

 
 * dogfood and take advantage of new kernel APIs (while maintaining
   portability to older Linux, free BSDs and maybe Hurd).
 
 * dogfood and take advantage of new kernel APIs (while maintaining
   portability to older Linux, free BSDs and maybe Hurd).


@@ -84,9 +84,13 @@ all need to be considered for everything we introduce)
 * use REQUEST_URI properly for CGI / mod_perl2 compatibility
   with Message-IDs which include '%' (done?)
 
 * use REQUEST_URI properly for CGI / mod_perl2 compatibility
   with Message-IDs which include '%' (done?)
 

-* more and better test cases (use git fast-import to speed up creation)
+* better test cases, make faster by reusing more setup
+  code across tests

 
 

-* large mbox/Maildir/MH/NNTP spool import (see PublicInbox::Import)
+* large mbox/Maildir/MH/NNTP spool import (in lei, but not
+  for public-facing inboxes)
+
+* MH import support (read-only, at least)

 
 * Read-only WebDAV interface to the git repo so it can be mounted
   via davfs2 or fusedav to avoid full clones.
 
 * Read-only WebDAV interface to the git repo so it can be mounted
   via davfs2 or fusedav to avoid full clones.


@@ -107,7 +111,8 @@ all need to be considered for everything we introduce)
 
 * code repository integration (cgit: done, TODO: gitweb, etc...)
 
 
 * code repository integration (cgit: done, TODO: gitweb, etc...)
 

-* migration path to v2 without breaking v1 "git fetch" cronjobs
+* migration path to v2 (making it transparent for "git fetch"
+  may not be possible, but "public-inbox-fetch" will handle it)

 
 * imperfect scraper importers for obfuscated list archives
   (e.g. obfuscated Mailman stuff, Google Groups, etc...)
 
 * imperfect scraper importers for obfuscated list archives
   (e.g. obfuscated Mailman stuff, Google Groups, etc...)


@@ -120,38 +125,18 @@ all need to be considered for everything we introduce)
   as extensions.  If JMAP, it should have HTTP(S) analogues to
   various IMAP extensions.
 
   as extensions.  If JMAP, it should have HTTP(S) analogues to
   various IMAP extensions.
 

-* search across multiple inboxes, or admin-definable groups of inboxes
-
-  This will require a new detached Xapian index that can be used in
-  parallel with existing per-inbox indices.  Using ->add_database
-  with hundreds of shards is unusable in current Xapian as of
-  August 2020 (acknowledged by Xapian upstream).
-

 * scalability to tens/hundreds of thousands of inboxes
 
 * scalability to tens/hundreds of thousands of inboxes
 

-  - pagination for WwwListing
-

   - inotify-based manifest.js.gz updates
 
   - inotify-based manifest.js.gz updates
 

-  - process/FD reduction (needs to be slow-storage friendly)
-

   ...
 
   ...
 

-* command-line tool (similar to mairix/notmuch, but solver+git-aware)
-
-* consider removing doc_data from Xapian, redundant with over.sqlite3
-  It's no longer read as of public-inbox 1.6.0, but still written for
-  compatibility.
-
-* share "git cat-file --batch" processes across inboxes to avoid
-  bumping into /proc/sys/fs/pipe-user-pages-* limits
+* lei - see %CMD in lib/PublicInbox/LEI.pm
+  (there's a truckload here..)

 
 * make "git cat-file --batch" detect unlinked packfiles so we don't
   have to restart processes (very long-term)
 
 
 * make "git cat-file --batch" detect unlinked packfiles so we don't
   have to restart processes (very long-term)
 

-* support searching based on `git-patch-id --stable` to improve
-  bidirectional mapping of commits <=> emails
-

 * linter to check validity of config file
 
 * linter option and WWW endpoint to graph relationships and flows
 * linter to check validity of config file
 
 * linter option and WWW endpoint to graph relationships and flows


@@ -167,3 +152,7 @@ all need to be considered for everything we introduce)
   (linkification is too expensive, as it requires mirroring)
 
 * support UUCP addresses for legacy archives
   (linkification is too expensive, as it requires mirroring)
 
 * support UUCP addresses for legacy archives

+
+* support pipelining as an IMAP/NNTP client for -watch + lei
+
+* auto-detect and reload on TLS cert+key changes in daemons