[Mailman-Developers] Interface to Archivers

[Jeffrey C. Ollie]

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6HhL9mCSL+rEqeRsRAvoMAJ9ZmUkm3+XFtRfjfnibP2E9AIQh4QCgmeAo
NNxpNdKGCU5dbeDMpSa+ca4=
=DC7Y
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--