TODO items for public-inbox
-(Not in any particular order)
+(Not in any particular order, and
+performance, ease-of-setup, installation, maintainability, etc
+all need to be considered for everything we introduce)
-* mailmap support (same as git) for remapping expired email addresses
+* general performance improvements, but without relying on
+ XS or compiled code any more than we currently do.
-* WWW: Hybrid flat view + thread skeleton (requires Xapian)
+* mailmap support (same as git) for remapping expired email addresses
* POP3 server, since some webmail providers support external POP3:
https://public-inbox.org/meta/20160411034104.GA7817@dcvr.yhbt.net/
* Optional reply-to-list support for mirroring lists that want it :<
Reply-to-list encourages the existing list as a single-point-of-failure,
- but having an extra mirror using public-inbox.org is nice regardless.
+ but having an extra mirror using public-inbox code is nice regardless.
* Configurable linkification for per-inbox shorthands:
"$gmane/123456" could be configured to expand to the
* handle Xapian date range queries:
http://mid.gmane.org/20151005222157.GE5880@survex.com
+* Consider storing git blob ID in Xapian doc data to avoid ref
+ and tree lookups based on Message-Id.
+
+* 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...)
+
+* Allow in-place Xapian updates without clobbering the whole
+ index (versioning each doc data entry?) for big archives
+
* use REQUEST_URI properly for CGI / mod_perl2 compatibility
with Message-IDs which include '%' (done?)