Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote:
> On Tue, Sep 07, 2021 at 10:14:04PM +0000, Eric Wong wrote:
> > > One of the
> > > options I want to investigate is making IMAP/POP3 accessible individual
> > > mailboxes fed by lei, such that a new subsystem maintainer could have a
> > > ready-made mailbox available to them without needing to 
> > > subscribe/unsubscribe
> > > to a bunch of mailing lists. (This would be different from read-only imap
> > > mailboxes offered by public-inbox-imapd, since we'll be tracking 
> > > individual
> > > message state. The POP3 bit would allow them to plug it into something 
> > > like
> > > Gmail which allows sucking down remote POPs.)
> > 
> > I think using the "-o v2:..." option for now would be the way to
> > go for making a v2 inbox available via -imapd (and it'll get
> > JMAP/POP3 support in the future).
> 
> I'm worried that read-only imap folders are going to cause problems for dumber
> imap clients, including mbsync. My goal is to make it easy for folks to use
> existing tools to which they are already accustomed, since my experience is
> that if the learning curve is too steep or requires too much fiddling to
> configure, the uptake is going to be extremely limited.

Agreed with read-only IMAP being a problem for existing clients.

lei is gradual in that approach in you can pick and choose which
parts to use.  It's actually close to being able to offer
<mbsync||offlineimap> functionality, but it's a bit clumsy
usage-wise atm:

        lei import imaps://example.com/folder

        # lei <q|lcat> results dumped to Maildir
        # inotify reads Maildir keyword updates done by MUA

        lei export-kw imaps://example.com/folder

I'm working on making the "export-kw" part transparent like it
mostly is with Maildirs.

The one thing lei doesn't do right now is deleting messages
from IMAP folders (unless it's overwriting search results).
That will probably be a separate command:

        lei prune-mfolder [--expire=...]

I hope to stop using <mbsync||offlineimap> myself, soon...

> On the other hand, a service that offers full search-based imap/pop3 folders
> is going to be an easy sell:
> 
> - it works with any imap client as a simple extra account
> - it can be mirrored locally and synced two-ways via mbsync

POP3 would be significantly easier to support server-side with
multiple users since it won't need to store per-user keywords.

Since lei is a daemon and can support multiple users, it could
have an R/W JMAP||IMAP front-end, though...

> - it can be incorporated into existing services like gmail, so people can
>   monitor things on the go

POP3 seems excellent for integrating into large mail providers.
I mainly haven't gotten around to implementing it, nor figuring
out how to deal with account management...

> - I can do clever things like suspend "lei up" runs if there was no access to
>   the folder for over N weeks
> - we can use FS dedupe features since all messages are going to be
>   identical after writing them out to maildirs

I've been thinking of making lei storage accessible as Maildirs
via FUSE, as well.

> The slightly harder part is making it easy for people to configure their
> search parameters, but I'm hoping to expose this via a git repo.

*shrug*  I've been trying to keep the learning curve as low as
possible by using most of the same prefixes as mairix (lei only
adds L: and kw: for labels and keywords).
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/

Reply via email to