X-Git-Url: http://www.git.stargrave.org/?p=public-inbox.git;a=blobdiff_plain;f=TODO;h=9396f66113750f26d17a761357850d24c08eea30;hp=a327ca0604a28fafd442425cd8fba2d601f339ec;hb=03c9119ec613fa43dcf0a50b5f35754f13228bc8;hpb=6b712fd2ee2d484de02150936d2a37e1bad9f61e diff --git a/TODO b/TODO index a327ca06..9396f661 100644 --- a/TODO +++ b/TODO @@ -6,23 +6,33 @@ all need to be considered for everything we introduce) * general performance improvements, but without relying on XS or pre-built modules any more than we currently do. + (Optional Inline::C and user-compiled re2c acceptable) * mailmap support (same as git) for remapping expired email addresses +* support remapping of expired URLs similar to mailmap + (coordinate with git.git with this?) + * POP3 server, since some webmail providers support external POP3: 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 +* HTTP, IMAP 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. +* support HTTP(S) CONNECT proxying to NNTP for users with + firewall problems + +* DHT (distributed hash table) for mapping Message-IDs to various + archive locations to avoid SPOF. + * optional Cache::FastMmap support so production deployments won't - need Varnish (Varnish doesn't protect NNTP, either) + need Varnish (Varnish doesn't protect NNTP or IMAP, either) * dogfood and take advantage of new kernel APIs (while maintaining portability to older Linux, free BSDs and maybe Hurd). @@ -32,12 +42,14 @@ 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 +* Combined "super server" for NNTP/HTTP/POP3/IMAP to reduce memory, + process, and FD 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 @@ -65,10 +77,9 @@ all need to be considered for everything we introduce) * linkify thread skeletons better https://public-inbox.org/git/6E3699DEA672430CAEA6DEFEDE6918F4@PhilipOakley/ -* streaming Email::MIME replacement: currently we generate many - allocations/strings for headers we never look at and slurp - entire message bodies into memory. - (this is pie-in-the-sky territory...) +* 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?) @@ -94,19 +105,38 @@ 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. +* extend public-inbox-watch to support IMAP, NNTP * improve performance and avoid head-of-line blocking on slow storage +* HTTP(S) search API (likely JMAP, but GraphQL could be an option) + It should support git-specific prefixes (dfpre:, dfpost:, dfn:, etc) + as extensions. If JMAP, it should have HTTP(S) analogues to + various IMAP extensions. + +* search across multiple inboxes, or admin-definable groups of inboxes + +* 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 + * share "git cat-file --batch" processes across inboxes to avoid bumping into /proc/sys/fs/pipe-user-pages-* limits @@ -119,7 +149,8 @@ all need to be considered for everything we introduce) * linter to check validity of config file * linter option and WWW endpoint to graph relationships and flows - between inboxes, addresses maildirs, coderepos, etc... + between inboxes, addresses, Maildirs, coderepos, newsgroups, + IMAP mailboxes, etc... * pygments support - via Python script similar to `git cat-file --batch' to avoid startup penalty. pygments.rb (Ruby) can be inspiration, too. @@ -133,3 +164,8 @@ all need to be considered for everything we introduce) for coderepos * configurable diff output for solver-generated blobs + +* figure out how search for messages with multiple Date: headers + should work (some wacky examples out there...) + +* support UUCP addresses for legacy archives