X-Git-Url: http://www.git.stargrave.org/?p=public-inbox.git;a=blobdiff_plain;f=TODO;h=7a27fdd2f716e80d1542c94a00662e42c5b90ba3;hp=8e1f4eaf1298e00a1886cf393538f0046868e15e;hb=23af251dd607c4e75ab1e68063f2c885c48cc035;hpb=8e9d4f877730dbdf4ebbd59cbd73a7a921c640e0 diff --git a/TODO b/TODO index 8e1f4eaf..7a27fdd2 100644 --- 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 - 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). @@ -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?) -* 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. @@ -107,7 +111,8 @@ all need to be considered for everything we introduce) * 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...) @@ -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. -* 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 - - pagination for WwwListing - - 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) -* 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 @@ -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 + +* support pipelining as an IMAP/NNTP client for -watch + lei + +* auto-detect and reload on TLS cert+key changes in daemons