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

From: Eric Wong <[email-masked]>
Date: Tue, 16 Jun 2020 07:08:32 +0000

Eric Wong <[email-masked]> wrote:
> Denton Liu <[email-masked]> 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/[email-masked]/

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