[Mailman-Developers] any interest in a new built-in web-archive? (i.e. pipermail replacement)

[Barry Warsaw]

On Mar 27, 2012, at 10:34 AM, Stephen J. Turnbull wrote:

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

fsvo "bundled" :)

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

Kind of.  Communication *into* Mailman is via LMTP, but sending a message out
of mm3 into the archiver can be hidden behind the IArchiver interface.  The
prototype archiver, just opens a maildir and adds the new message to that.
The mailarchive implementation drops the message into the outgoing queue, but
with a recipient as specified in the configuration file.  The mhonarc archiver
calls a subprocess and pipes the message's bytes to that process's stdin.  The
moral is that whatever you need to do to get the message into the archiver,
you can do it.

You're right about the algorithm for calculating the X-Message-Id-Hash.  Full
details are on the wiki.  The intent here is to be able to calculate the URL
to the message in the archiver without actually having to communicate with the
archiver.

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

Yep.

I've also been thinking; we have an IMessageStore interface which currently
isn't much hooked up in any way.  It's possible that a specific archiver could
satisfy the IMessageStore API as well, and that eventually we could implement
things like a mail command that, given a Message-ID (or its hash) would send
you back the message from the store.

>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

I've been thinking that the prototype archiver could be this thing.  Well, it
already essentially *is* that thing!  So, it's not in a handler, but gets
invoked from the ArchiveRunner.

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

+1

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

Definitely.

My intent with mm3 is to provide an enabling platform for archiver
developers.  I think there's lots of opportunity for experimentation here, so
let's make sure we get the API between mm3 and a generic archiver right.
We'll see what pans out and then we can choose a preferred default that we can
bless and bundle in some kind of sumo release.

Cheers,
-Barry