user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
* [PATCH] TODO: remove done items, adjust/add/abandon some
@ 2022-08-04  7:23 Eric Wong
  2022-12-09  1:41 ` FUSE3 vs read-write IMAP for lei Eric Wong
  0 siblings, 1 reply; 2+ messages in thread
From: Eric Wong @ 2022-08-04  7:23 UTC (permalink / raw)
  To: meta

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

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* FUSE3 vs read-write IMAP for lei
  2022-08-04  7:23 [PATCH] TODO: remove done items, adjust/add/abandon some Eric Wong
@ 2022-12-09  1:41 ` Eric Wong
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Wong @ 2022-12-09  1:41 UTC (permalink / raw)
  To: meta

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...

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-12-09  1:41 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-04  7:23 [PATCH] TODO: remove done items, adjust/add/abandon some Eric Wong
2022-12-09  1:41 ` FUSE3 vs read-write IMAP for lei Eric Wong

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).