On Tue, Mar 27, 2012 at 7:20 AM, David Jeske davidj@gmail.com wrote:

I'm writing to find out the state of and philosophy surrounding pipermail in mailman,

There's been a lot of discussion of this over the years; you should spend some time in the mailman-developers and mailman-users archives looking for it, because neither the needs nor Barry's philosophy have changed much over that time period. It would be really nice if somebody would summarize it in Python-PEP fashion, but that's above and beyond the call of duty from your point of view. (Ie, it would be useful, but you may prefer coding etc, and that's fine too I believe, though I don't speak for Barry, although I occasionally get lucky channeling him ;-).

 Unfortunately, pipermail doesn't do a good job formatting messages for html.. (messages with no line-breaks are the most annoying problem I regularly run into)

Doing a *better* job of formatting HTML (than pipermail) is easy. Doing a *good* job is going to be relatively hard, though.

If there is some code (and time) I can contribute to mailman/pipermail, I'd like to do so.

A better pipermail probably would be a good thing, as transition to Mailman 3 is likely to take several years, and Mailman 2 is likely to continue to be used for several years. However, IMO you should focus on low-hanging fruit, as there are now much better alternatives to the technology used in pipermail, to the point where rewriting from scratch (or adapting a 3rd-party product) for Mailman 3 makes sense.

a) pipermail is fine... if you want to fix a bug or two submit a patch, but we don't want to improve it

Pipermail is fine for EOLing Mailman 2. Improving it would be good, but only if archive formats don't need upgrading and at minimum expense of effort, IMO.

b) we're ditching pipermail entirely... in the future sites will have to choose an install an external archiver

Pipermail is going the way of the dodo, yes, but there will be something bundled with Mailman, I'm pretty sure.

d) we'd love a dynamic-ui replacement for pipermail... as long as it uses the same cgi/templating model as mailman ui

A dynamic UI replacement seems to be a very good idea to me. Sites running mailman at all will be running a dynamic UI for the admin, so I see no good reason to stick to static for the archives.

AIUI, the current philosophy is that

(1) the communication from Mailman to the archivers will be via LMTP/SMTP, including a Mailman-specific header to identify the message's permalink (currently the SHA1 hash of the message ID in BASE32 format, IIRC); and

(2) the summary, search, and retrieval UI will be a separate application from Mailman per se, which will communicate with Mailman via the REST API for authentication and user configuration purposes.

Some ideas that have *not* been elaborated as "philosophy", but which I think are consistent with various desiderata and Barry's general approach and specific statements are

(3) an archiver Handler for the pipeline will be provided, which will store posts in maildir format and do nothing else; and

(4) a simple default summary/search/retrieval application will be bundled with (but have a separate development cycle from) Mailman.

Even if that's not the current philosophy <wink/> that's the direction I would propose.

So if you have already developed some stuff, I certainly would love to see you put it on the table as a candidate for the Mailman 3 default archive web UI.