[Python-ideas] Browser for mailing lists

[Cameron Simpson]

On 31Mar2014 14:07, Stephen J. Turnbull <turnbull at sk.tsukuba.ac.jp> wrote:
> N.B. This is off-topic.  If you really care that much, people who want
> to hear about it are over on mailman-developers at python.org.

I may join that list, though I'd be an informed commenter (== whinger)
rather than a dev.

> Cameron Simpson writes:
>  >   - the mbox archive URLs (often gzipped) don't come down with a
>  >     cool MIME type meaning "UNIX mailbox format"
> 
> There isn't one, can't be one at present, and likely won't be one in
> the future: http://www.jwz.org/doc/content-length.html.  This still
> applies to some extent today despite Jamie's rant being almost 20
> years old -- Mailman can't choose the mbox spec being used, that
> depends on the MTA.

It can cheerfully choose the mbox spec for delivery of an archive.
It is very simple and is a single flat file. As a bonus, many MUAs
can read it directly.

I've seen JMZ's content-length rant in the past, or something
equivalent; if one documents what is being done an mbox can still
be delivered usefully to the end user. If one doesn't want
Content-Length headers in the archive format, the ">From" hack works
quite well. Conversely, if is perfectly possible to create valid
Content-Length heders when constructing the archive.

We're talking about an archive/transfer format here, not whatever
raw format one works with locally.

> If you want something that could actually have a MIME-Type, there's
> Babyl, MMDF, or (file-per-message) maildir, all of which have
> reasonably precise specs -- but aren't in anywhere near as wide use.

I meant the BSD mailbox format, often called mbox. I know there are
several minor variants, but if mailman (or whatever subcomponent)
documents its chosen flavour that's perfectly tractable.

> Maildir is what Mailman 3's bundled "trivial archiver" uses, as it's
> far more robust and easier to handle than mbox.

Maildir is great as a storage platform; I use it myself for many
folders. But as a delivery format for end users one then has to
pick some wrapper. Zip or tar or... mbox!

>  > I still content that any change that removes the simple ability to
>  > fetch the list archive for use by the end user is a huge step
>  > backwards, regardless of the prettiness of whatever replaces it.
> 
> It's not a question of "removing".  This has always been a user
> choice, and many lists use third-party services (mail-archive.com) or
> non-pipermail archivers (MHonArc).  It's just that Mailman 2 with its
> bundled mbox-format archiver made it easy to provide by default.

Effectively it is removal. If the python lists moved to mailman 3
and suddenly didn't have a "download the list archive", from an end
user point of view that is removal.

> If lots of users really prefer pipermail, for whatever reason, it's
> not that hard to add by hand, and could be packaged on PyPI.

Pipermail has two sides to it: the archive bundles and the message
browser. Plenty of things do a richer message browse (MHonArc seemed
quite nice when last I looked, many years ago).

I'm not wedded to pipermail; from a browsing point of view this new
thing may do well. And I've seen plenty of other simple things on
the net that expose the discussion threads nicely.

I'm wedded to having the archives available in a simple and easy
to fetch form, in a format that is easily imported by many MUAs.
Therefore: mbox.

When Google Groups became a popular site to host mailing lists I
became aghast at how crude and forumlike the interface is/was, and
how the historical list archive was effectively unavailable.  When
Google Groups sucked in the usenet archive tapes I was full of hope,
but I don't see those archives available for download either.

We have all chosen our preferred tool to read lists (be it in "mail"
or "usenet" forms); not being able to access old messages the same
way as current messages feels... shortsighted.


Cheers,
-- 
Cameron Simpson <cs at zip.com.au>

Archiving the net is like washing toilet paper! - Leader Kibo