Hash: SHA1

On Jul 2, 2007, at 11:06 PM, Terri Oda wrote:

> Since I've largely finished up the coding contract that was eating up
> a lot of my time, I'm thinking that I'd like to do some coding for
> fun.  And nothing says fun like trying to fix the Mailman archives! ;)

That would be awesome Terri!  It's an aspect of Mailman that sorely  
needs attention, and you will gain (even more) fame and fortune by  
working on it. :)  I totally support this effort.

> I'm trying to remember all the things people have suggested for the
> archives in the past so I can figure out what needs to be done and
> what might be nice to have, and see if this is doable in the time I
> have in the foreseeable future.
> The big things people wanted most, if I recall correctly, included:
> - modernized HTML/CSS/Themes (preferably to match a modernized web
> interface... is that all set up now?)

It's not, but Andrew Kuchling will be working on this.  I haven't yet  
revealed detailed plans, though I'm working on an email about this  
over the U.S. July 4th holiday.  But I suppose it's time for a quick  
summary: I'd like to get a Mailman 2.2 out with an updated u/i sooner  
rather than later, and if possible an updated archiver would be one  
of those few other new features that I think could go into a 2.2.   
OTOH, it would be fine if we pushed that off to Mailman 3 too, but it  
leveraged all the u/i work to be done in 2.2.

> - archive links that won't break if the archive is rebuilt

Yes, this is absolutely critical, in fact, I'd put it right at the  
top of the list, even more so than a u/i overhaul.  Stable urls, with  
backward compatible redirecting links if at all possible, would be  

Along with that, I would really like to come up with an algorithm for  
calculating those urls without talking to the archiver.  This would  
allow the list delivery queue to calculate the List-Archive: header  
value and any message header/footer substitutions before the message  
hits the archiver.

> - better address obfuscation (maybe by generating pages through cgi)

I'd still love to do this, and I think were it not for crawlers, we  
could get a lot of mileage out of creation on demand and caching.   
But how do you handle Google crawling your archive?

> - search

Another huge huge feature.

> - not adding a billion dependencies to Mailman

Definitely.  I'm also not opposed to changing the interface between  
Mailman and the archivers if necessary.

> Here's the list from the wiki's Mailman 2.2 page: http://
> wiki.list.org/display/DEV/Mailman+2.2

We should probably start a separate archiver wiki page.  I plan on re- 
organizing the 2.2 page anyway, so I'll probably end up doing that if  
you don't get around to it before me <wink>.

> (1) Is anyone working on this already?

Not that I know of.

> (2) What else is on people's wish lists for a pipermail replacement?

Other things high on my list are ditching the crufty storage  
currently being used (pickles begone!), an RSS feed, and a 'message  
storage' which could be used to vend archived messages through other  
delivery transports, such as imap or nntp.  But I'd be willing to put  
all that off for stable urls, an updated u/i, and searching.

Anything I can do to help, please let me know.

- -Barry

Version: GnuPG v1.4.7 (Darwin)

Mailman-Developers mailing list
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 

Security Policy: 

Reply via email to