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

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

[Eric Wong]

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

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

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> 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...

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

[Denton Liu]

Hi Eric,

On Tue, Jun 16, 2020 at 07:08:32AM +0000, Eric Wong wrote:
> Eric Wong <e@80x24.org> wrote:
> > 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/

Aha, I noticed last night when I was using it that it seemed much
snappier! I can also confirm on my end that your patch works and it
makes the experience much better.

Thanks again!