[Mailman-Developers] Parsing and Rendering rfc2822

emf i at mindlace.net
Thu Jul 6 00:37:21 CEST 2006


John Dennis wrote:

> It's not at all clear to me that mailman should be responsible for
> archiving.

While I am somewhat in agreement, the current situation is that 
archiving comes bundled with mailman and represents a significant 
weakness in its current web UI. Not doing anything about the web UI 
presented by the archives would, in my mind, represent a substantial 
failing.

> Archiving and MLM (Mailing List Manager) functionality can be
> orthogonal to each other.

I can imagine - but have never used - a mailing list where access to 
past emails is 'orthogonal' to the use of the mailing list. It is hard 
for me to see the orthogonality except inasmuch as there's often a 
different user agent involved.

> Archiving has a complex feature set if it's
> done right, and it's complex to implement.

Well, happily mailman is in the situation where archiving is not done 
right, and it seems like there's room for doing enough to a.) represent 
an improvement on the current situation and b.) lay a decent groundwork 
for plugging in different archivers or offering more of this complexity 
you speak of.

> There are many items on Mailman's UI task list which need attention and can be done
> independently of also trying to tackle the 800 pound gorilla known as
> archiving.

I am indeed taking this tack. However, even for things like the 
moderation approval page I need to parse & render emails.

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

> For what its worth I went looking for best of breed in open source
> archivers about 6 months ago and what I came up with was a project
> called "Lurker" (http://lurker.sourceforge.net)

Thanks! I will look into this and see what I can glean from it.

> IMHO let the archiving experts deal with archiving, let the MLM experts
> (e.g. Mailman) deal with managing mailing lists.

It is probably just a sign that I haven't explored the extant solutions 
sufficiently, but I have seen no sign that there are a variety of 
high-quality archiving solutions out there.

What appears to me to be your main point - don't let archiving get in 
the way of delivering other UI functionality - is well taken; it is not 
at all at the top of my queue.

~ethan fremen


More information about the Mailman-Developers mailing list