[Mailman-Developers] Parsing and Rendering rfc2822

[Barry Warsaw]

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