Re: CFT: imaps://public-inbox.org/INBOX.comp.version-control.git.7

From: Eric Wong <e@80x24.org>
Date: Jun 16, 2020, 07:08 UTC
Message-ID: <20200616070832.GA13965@dcvr>
In-Reply-To: <20200611003036.GA5446@dcvr>

Eric Wong <e@80x24.org> wrote:

Show 17 quoted lines

> Denton Liu <liu.denton@gmail.com> wrote:
> > Exciting news! Since I'm not actually subscribed to the mailing list,
> > public-inbox has been integral in my workflow by letting me reply to
> > messages that I'm not CC'd on. The IMAP gateway is a great development.
> > 
> > I fetched your message via IMAP just now ;)
> 
> Hi Denton, great to know you appreciate it :)
> 
> It's still in the early stages and there still seems to be a
> problem where it still interacts badly with mutt's header cache.
> Maybe checking over the old HTTPS/NNTPS endpoints once in a
> while if things appear too quiet is a good idea while I shake
> out some bugs.
> 
> I'm dreading the cost of ~100K RAM/storage overhead per-client
> connection to support sequence numbers properly...

OK, that ought to be fixed and I found what seems to be an acceptable solution w.r.t. server-side overhead: https://public-inbox.org/meta/20200612234924.GA31809@dcvr/

I've also just deployed a recursive descent parser for which is hopefully compliant with the way IMAP search queries are parsed: https://public-inbox.org/meta/20200616050540.13357-3-e@yhbt.net/

One of the annoyances of read-only IMAP is MUAs (unlike newsreaders) lack the ability to store status flags for new/unread messages. I've got some ideas to deal with that on the client-side...