threads / discuss / 53650

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

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

## tl;dr

6 messages between Jun 10, 2020 and Jun 23, 2020.

replies: 5people: 2as markdown or json

Eric Wong· Jun 10, 2020, 18:41 UTC · lore

Hey all, I've been busy with public-inbox work this year. I started working on a read-only IMAP/IMAPS server, and I expect kernel.org to eventually host a v2 copy, too; and hopefully other folks get interested in mirroring.

For now, you can access git@vger archives through 8 IMAP mailboxes sliced into ~50K messages to not overload clients. They go from 0..7, with 7 being the most recent:

imaps://public-inbox.org/INBOX.comp.version-control.git.0 imaps://public-inbox.org/INBOX.comp.version-control.git.1 imaps://public-inbox.org/INBOX.comp.version-control.git.2 imaps://public-inbox.org/INBOX.comp.version-control.git.3 imaps://public-inbox.org/INBOX.comp.version-control.git.4 imaps://public-inbox.org/INBOX.comp.version-control.git.5 imaps://public-inbox.org/INBOX.comp.version-control.git.6 imaps://public-inbox.org/INBOX.comp.version-control.git.7

When more messages show up, imaps://public-inbox.org/INBOX.comp.version-control.git.8 should exist.

I've tested with mutt, offlineimap and mbsync (isync).

It's not yet complete (when is software ever?), but it's a usable start, I think. Some more info about it over on meta@public-inbox.org: https://public-inbox.org/meta/20200609113442.GA16856@dcvr/ https://public-inbox.org/meta/20200610070519.18252-1-e@yhbt.net/ And maybe JMAP is coming, too...

Denton Liu· Jun 10, 2020, 23:31 UTC · re: Eric Wong · lore

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

Hi Eric,

On Wed, Jun 10, 2020 at 06:41:47PM +0000, Eric Wong wrote:

Show 30 quoted lines

> Hey all, I've been busy with public-inbox work this year.
> I started working on a read-only IMAP/IMAPS server, and I expect
> kernel.org to eventually host a v2 copy, too; and hopefully
> other folks get interested in mirroring.
> 
> For now, you can access git@vger archives through 8 IMAP
> mailboxes sliced into ~50K messages to not overload clients.
> They go from 0..7, with 7 being the most recent:
> 
> imaps://public-inbox.org/INBOX.comp.version-control.git.0
> imaps://public-inbox.org/INBOX.comp.version-control.git.1
> imaps://public-inbox.org/INBOX.comp.version-control.git.2
> imaps://public-inbox.org/INBOX.comp.version-control.git.3
> imaps://public-inbox.org/INBOX.comp.version-control.git.4
> imaps://public-inbox.org/INBOX.comp.version-control.git.5
> imaps://public-inbox.org/INBOX.comp.version-control.git.6
> imaps://public-inbox.org/INBOX.comp.version-control.git.7
> 
> When more messages show up,
> imaps://public-inbox.org/INBOX.comp.version-control.git.8
> should exist.
> 
> I've tested with mutt, offlineimap and mbsync (isync).
> 
> It's not yet complete (when is software ever?), but it's a
> usable start, I think.  Some more info about it over on
> meta@public-inbox.org:
> https://public-inbox.org/meta/20200609113442.GA16856@dcvr/
> https://public-inbox.org/meta/20200610070519.18252-1-e@yhbt.net/
> And maybe JMAP is coming, too...

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 ;)

-Denton

Eric Wong· Jun 11, 2020, 00:30 UTC · re: Denton Liu · lore

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

Denton Liu <liu.denton@gmail.com> wrote:

Show 5 quoted lines

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

Eric Wong· Jun 16, 2020, 07:08 UTC · re: Eric Wong · lore

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

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

Denton Liu· Jun 16, 2020, 13:19 UTC · re: Eric Wong · lore

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

Hi Eric,

On Tue, Jun 16, 2020 at 07:08:32AM +0000, Eric Wong wrote:

Show 7 quoted lines

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

Eric Wong· Jun 23, 2020, 18:08 UTC · re: Eric Wong · lore

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

+Cc: Christian for Git Rev News 64

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

> When more messages show up,
> imaps://public-inbox.org/INBOX.comp.version-control.git.8

They've showed up, and .8 now exists, bringing to total up to 9.