From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id EEA6C1F8C6; Wed, 8 Sep 2021 14:49:48 +0000 (UTC) Date: Wed, 8 Sep 2021 14:49:48 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: Showcasing lei at Linux Plumbers Message-ID: <20210908144948.GA380@dcvr> References: <20210902211225.pmnykwcwcxeaunt5@meerkat.local> <20210902215850.GA5063@dcvr> <20210907213337.zir2mes6fiy4lbw7@meerkat.local> <20210907221404.GB17787@dcvr> <20210908133615.grlzysueyxwgcoyn@meerkat.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210908133615.grlzysueyxwgcoyn@meerkat.local> List-Id: Konstantin Ryabitsev 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 functionality, but it's a bit clumsy usage-wise atm: lei import imaps://example.com/folder # lei 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 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).