It would seem to me that the discussion so far regarding the "future of pipermail" is going too far in the direction of discussing "what would the most keenest archiver look like" rather than discussing "what should the interface between the Mailman and an archiver look like" and "what should the default archiver look like". So to try and steer the discussion in this direction, here I go sticking my foot in my mouth:
What Should the Interface Between Mailman and an Archiver Look Like:
def submit(mlist, msg) archiver = __import__('Mailman.Archivers.' + mm_cfg.ARCHIVE_MODULE) submit = getattr(getattr(getattr(mod, 'Archivers'), mm_cfg.ARCHIVE_MODULE), 'submit') urls = submit(mlist, msg) return urls
The 'urls' returned from the archive module will be a data structure that includes a URL that points to the archived message as a whole and optionally URLs that point to individual MIME-decoded individual parts. If the archiver includes URLs for individual parts Mailman could optionally reformat the message to remove attachments and replace them with a pointer to the archive.
So then we write any number of modules that interface to popular archivers, plus we include a simple default archiver (IMHO, in the same tarball as the Mailman). This way, the details of the archiver are completely hidden from Mailman and adding support for new archivers is very simple. I suppose that one could even add support for different archivers for every list.
What Should the Default Archiver Look Like:
It'll look a lot like pipermail, in that it stores archived messages in files on a filesystem. Indexes and tables of contents will be rebuilt as needed and saved in static files. It'll look different from pipermail in that MIME message parts will be decoded and be accessible as individual files.
The reason for going with files stored on a filesystem is that it's very simple. No database to deploy and no fancy web server is required.
More complex schemes are of course possible by writing the appropriate plug-in.
Jeff