[PATCH] TODO: remove done items, adjust/add/abandon some

[PATCH] TODO: remove done items, adjust/add/abandon some

[Eric Wong]

public-inbox-pop3d (and -netd) gives us POP3 support, and
it seems to work.  Proxy support can come independently,
probably after JMAP.

public-inbox-netd provides the multi-protocol "super server"
which allows code memory savings.  Work is ongoing to further
reduce memory use...

Automatically updating on TLS cert and key changes on
inotify/EVFILT_VNODE won't be done, since (IMHO) there's too
much risk of inadvertent updates on incomplete changes.
My same train-of-thought applies to auto-reloading on config
file changes: an admin may save a file halfway through a
multi-step change and auto-reloading can be too surprising and
break things.

I don't think lei+FUSE will be as portable or useful as a
local IMAP server (and maybe JMAP, eventually); but r/w IMAP
support would be nice..

Finally, git SHA-256 repo support will need to be taken into
account.
---
 TODO | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/TODO b/TODO
index 7a27fdd2..36055911 100644
--- a/TODO
+++ b/TODO
@@ -13,19 +13,13 @@ all need to be considered for everything we introduce)
 * 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 git repositories.
-
-* HTTP, IMAP and NNTP proxy support.  Allow us to be a frontend for
+* HTTP, IMAP, NNTP, POP3 proxy support.  Allow us to be a frontend for
   firewalled off (or Tor-exclusive) instances.  The use case is
   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
+* support HTTP(S) CONNECT proxying to IMAP/NNTP/POP3 for users with
   firewall problems
 
 * DHT (distributed hash table) for mapping Message-IDs to various
@@ -44,9 +38,6 @@ all need to be considered for everything we introduce)
 * Support more of RFC 3977 (NNTP)
   Is there anything left for read-only support?
 
-* 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.io list archives,
@@ -155,4 +146,6 @@ all need to be considered for everything we introduce)
 
 * support pipelining as an IMAP/NNTP client for -watch + lei
 
-* auto-detect and reload on TLS cert+key changes in daemons
+* expose lei contents via read/write IMAP/JMAP server for personal use
+
+* git SHA-256 migration/coexistence path

FUSE3 vs read-write IMAP for lei

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> I don't think lei+FUSE will be as portable or useful as a
> local IMAP server (and maybe JMAP, eventually); but r/w IMAP
> support would be nice..

One thing about lei which really bothers me is that it needs to
write out mail already in local git repos to the FS to be read
by regular MUAs.

This is wasteful, of course; so there's 2 ways I can imagine
exposing mail to ordinary MUAs without excessive disk
traffic/wear:


== read-write IMAP for lei

* connect via localhost (127.0.0.1, [::1]) (don't think local sockets
  are supported by any MUAs)

* May be extended to JMAP; but it's hard to be motivated on JMAP
  since my favorite MUA doesn't do JMAP, yet.

+ portable (can be done in pure Perl + DBD::SQLite + Xapian)

+ we already have a read-only IMAP server which can be extended
  for read/write

- still needs login w/ username+password due to multi-user systems

- may still susceptible to abuse and from multi-user systems

- IMAP gets pretty complex, and MUAs sometimes don't do it well



== FUSE3 - Maildir-oriented FS


+ will require C compiler since old FUSE XS modules don't do
  FUSE3 (for readdirplus); and going w/o readdirplus is
  unimaginable for Maildir.

+ I already have existing (unreleased) AGPL-3 work based on
  FUSE3 + URCU + Perl5 with just-ahead-of-time (JAOT) compilation

* I've seen the light w/ URCU, and can't go back to C without it :P

- likely Linux-only (not sure how good FUSE support will be if
  depending on FUSE3 features)

- kernel caches still incur nasty memory overhead w/ Maildir

- readdir(3) userspace API still sucks


Of course, doing both is an option, too, given enough time...

Re: FUSE3 vs read-write IMAP for lei

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> == FUSE3 - Maildir-oriented FS
> 
> + will require C compiler since old FUSE XS modules don't do
>   FUSE3 (for readdirplus); and going w/o readdirplus is
>   unimaginable for Maildir.
> 
> + I already have existing (unreleased) AGPL-3 work based on
>   FUSE3 + URCU + Perl5 with just-ahead-of-time (JAOT) compilation

Fwiw, I've pushed out a new "fuse3" branch to public-inbox.git:

https://80x24.org/public-inbox.git/80ce906027eeb7b4cc5cc7d3858294927951988a/s/

I think I need some C + URCU in my life to keep my brain working

> * I've seen the light w/ URCU, and can't go back to C without it :P
> 
> - likely Linux-only (not sure how good FUSE support will be if
>   depending on FUSE3 features)

Well, I got rid of the futex requirement from the original...

> - kernel caches still incur nasty memory overhead w/ Maildir
> 
> - readdir(3) userspace API still sucks