On 31Mar2014 14:07, Stephen J. Turnbull email@example.com wrote:
N.B. This is off-topic. If you really care that much, people who want to hear about it are over on firstname.lastname@example.org.
I may join that list, though I'd be an informed commenter (== whinger) rather than a dev.
Cameron Simpson writes:
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.
Cameron Simpson email@example.com
Archiving the net is like washing toilet paper! - Leader Kibo