Re: setting up mailman-to-atom-converter then atom-to-public-inbox

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Tue, Feb 4, 2020 at 9:05 PM Eric Wong <e@yhbt.net> wrote:

> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > hi, just as the subject says, i'm currently modifying mailman_rss to
> > support atom and would like to set it up on libre-soc.org shortly.
> >
> > firstly: very grateful that public-inbox even exists, it is kinda
> > important to have really, really simple offline archives of project
> > mailing lists.
>
> You're welcome :>
>
> > second: i have no idea how to go about setting it up :)
>
> Once installed, "public-inbox-init" should get you started.
> From there, you can decide how you want to inject mail into
> it...

ahh exxcellent....  err... err.... man public-inbox-config only lists
Maildir not mbox?

> We should be able to clarify anything else here, just ask,
> and we can try to make the docs better :>
> Fwiw, I also started working on a mail flow diagram yesterday,
> which may help:
>
>         https://public-inbox.org/flow.txt

excellent.  very useful.

> > third: sigh, i have two unknowns (three), because i am actually
> > modifying mailman_rss to support atom, *and* i would prefer not to
> > overload my server by splitting up the creation of atom feeds into
> > multiple separate processing sections (by month) *and* i have no idea
> > if public-inbox can support feeds-of-feeds.
>
> This is your Mailman server?

yes

> If so, mbox or Maildir archives
> would be MUCH easier to convert and it would preserve
> Message-Id, References, and In-Reply-To headers for proper
> message threading.

errr... errr doh!  ok so the mbox archives are private under one
account and i need to publish them via... gitweb, so that's ok.

> public-inbox doesn't have any ability to parse Atom or RSS right
> now, it only generates Atom.

aw doh!  that's where i got the impression i had to *read* the atom
feed (doh).  well, i have some nice modifications to mailman_rss which
uses a generic "Feed" python module i found, i will publish later :)

> Parsing Atom (or RSS) would not preserve headers necessary for
> proper threading, since Atom threading headers (RFC4685) don't
> reliably map back to the aforementioned mail headers.

red herring....

> > to explain / unpack that: here's how i would envisage the workflow so
> > as to minimise the server load:
> >
> > * cron job goes through the monthly mailman archives *by month*
> > performing a re-creation *only* of the latest month's atom feed
> > * same cron job adds to a "global" atom file containing "links to the
> > monthly atom files"
> > * public-inbox sees that list-of-monthly-atom-files
> > * public-inbox walks the "tree" of monthly atom files, grabbing each one in turn
> > * public-inbox loads all messages from all monthly atom files.
>
> s/atom/mbox/ and that's close to a planned feature.

oh superb.

> I'm not sure why the global index file is necessary, though,
> since the tree structure is predictable (YYYY/MM or similar)

i was imagining that there would be a way to reduce network traffic
however i realise now that you're running the cron job actually on the
machine, directly on the .mbox file.

> public-inbox itself uses the Email::MIME module, which
> unfortunately requires reading an entire RFC-2822 message into
> memory (and we only work on one full message at a time).

*shudder* :)

> Beyond that, the message threading in the HTML output
> (non-recursive JWZ-variant) works on a batch of 1000 message
> skeletons (subset of headers), and few threads are that big.

yehyeh.

okaay, so i'm looking at man public-inbox-config, it says "only
supports Maildir".  grep the source, there's something about
PublicInbox::Import.pm?

ngggh how am i going to get mbox files in / watched?

thanks eric.

l.