-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 6:37 PM, emf wrote:
>> I seem to >> recall this is also Barry's preference who noted the existing >> pipermail >> was only a stop-gap solution so there would be some default archiver, >> but it was never the intention Mailman would have any extensive >> archiving implementation. > > Like many stop gap solutions, this one is widely used, and represents > the most visited portion of the "mailman web UI". At a bare > minimum, the > archive pages should provide decent navigation. > > The requirement for a default archiver remains, and the solution I > propose is much more override friendly than the existing one; it > wouldn't create hundreds of webpages out of the archives, just read > out > of the existing mbox files. Pipermail was originally a separate project, developed by Andrew Kuchling IIRC. A looonngg time ago it was integrated into Mailman, but not in a terribly clean way (e.g. inheritance through cut-and- paste). I don't think Andrew's been interested in Pipermail for years. My own position on Pipermail and archiving is that Mailman should come with a default archiver that is minimally useful for simple sites, and that the Python-based Pipermail makes the most sense to serve as this default, simplistic archiver. It keeps packaging, dependencies, and deployment very simple. I'm open to suggestions for alternatives though. (Or ideally, some young college student with lots of free time to devote unending hours to improving Pipermail, at the expense of family, sleep, social life and studies. That, or get Tim Peters interested.) However, it should be very easy to integrate any other archiver with Mailman, and to the extent that current APIs need to be improved, I'm all for that. If you have a pet archiver that requires changes to Mailman to work better, please let us know! Pipermail's lack of a default search feature is its biggest (but by no means only) problem. I'd like to see this addressed, if it can be done cleanly, in MM2.2. I'd favor a Python solution here, for the same reasons as above but again, pluggability would be favored over a hard coded connection. Other than that, it's clear that Pipermail's web u/i is so 1995, and needs a major overhaul. For example, just as you'd like Mailman's web u/i to be easily integrated into the L&F of a site, so too for the Pipermail interface. The major problem with that though is that because Pipermail generates its pages statically, and because of various bugs and misfeatures in earlier versions, any regeneration of the static pages to a new u/i carries with it a high potential to break existing links. Honestly, I don't think there's any good solution to link breakage, so I think the right thing to do is to be able to preserve the current u/i and link algorithm unless the new one is explicitly enabled. And if the archives are regenerated with a new u/i, we should ensure that the link urls will be much more persistent than they currently are, probably based on a guaranteed unique Message-ID or other header-based identifier. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRKxHbXEjvBPtnXfVAQJokwQAsfoFnAp4zBW/1TQXiKqADTf3GIGV1v2u 10NLSlsj11kftf2mSANqTDZvFB/oquzG7f2UBNU1OUtOQhH9guneywLcAnxcmH3o bu1yzcA2dm0AslVPonyg76ps7KERNGK5s4Dw181jlCvjZiyloYi5m+LJhMjQSvNP j4wUyt4CvrI= =j6G0 -----END PGP SIGNATURE----- -- http://mail.python.org/mailman/listinfo/python-list
