[Mailman-Developers] any interest in a new built-in web-archive? (i.e. pipermail replacement)

[Toshio Kuratomi]

On Mon, Mar 26, 2012 at 03:20:05PM -0700, David Jeske wrote:
> I'm writing to find out the state of and philosophy surrounding pipermail
> in mailman, to see if there is a productive way to provide some
> code/development-time to that part of mailman.
> 
> I know there are several decent third-party archivers out there, but many
> of the mailing list archives I browse regularly are using pipermail because
> it's the mailman default.... one less thing to install, administer, and
> upgrade.  Unfortunately, pipermail doesn't do a good job formatting
> messages for html.. (messages with no line-breaks are the most annoying
> problem I regularly run into)
> 
> I've written code for this a number of times (eGroups, Yahoo Groups, Google
> Groups). I also released an open-source python/clearsilver/sqlite based
> archiver with redundant text-eliding, a few different thread views, and
> search...  ( http://www.clearsilver.net/archive/ ) which is hardly used
> both because I don't try to popularize it, and because many sites just
> leave the default (pipermail).
> 
> If there is some code (and time) I can contribute to mailman/pipermail, I'd
> like to do so. I'm writing this message to "take a temperature" and find
> out what, if any, contributions would be appreciated the mailman
> development team. I could imagine answers like:
> 
> a) pipermail is fine... if you want to fix a bug or two submit a patch, but
> we don't want to improve it
> b) we're ditching pipermail entirely... in the future sites will have to
> choose an install an external archiver
> c) we'd love pipermail to be improved... but we still want it to be simple,
> static-html, and dependency free
> d) we'd love a dynamic-ui replacement for pipermail... as long as it uses
> the same cgi/templating model as mailman ui
> 
> Thoughts? Is there any help I can offer up here?
>
We'd love to have work done on the archier!  I know that we're ditching
pipermail entirely and that archivers are becoming separate from the core
mailman.  What I don't know is whether mailman3 will eventually have
a standard archiver which lives outside of the core mailman but is
recommended for installation along with it.

At PyCon a few weeks ago, I demoed hyperkitty which showed some of the
things that a next generation archiver could do.  hyperkitty is continuing
to be developed.  As I was talking about hyperkitty we touched briefly on
what I think is one of the central conundrums about having only unofficial
third party archivers:  how to have a consistent programatic interface
available over http.  Grackle is another archiver for mailman that doesn't
have the UI bells and whistles of hyperkitty but it does make an effort to
expose a REST UI to the world.  I think that's a beautiful thing.  But
I don't like that a site that wanted both would need to run two archivers
that were saving mail into two sets of storage.

I think there's several ways we could go about this.

* We could create a standard REST API that archivers were free but
  encouraged  to implement.
* We could expand the python API that archivers needed to expose and then
  implement the REST API inside of mailman Core (or a re-envisioned,
  lightweight Grackle).
* We could promote a standard archiver much as we're going to promote
  posterius as the standard admin front-end and that archiver would provide
  a standard REST API that others could then emulate.


hyperkitty:
Project page: https://fedorahosted.org/hyperkitty/
Code: http://bzr.fedorahosted.org/bzr/hyperkitty/
Demo: http://mm3test.fedoraproject.org/2

grackle: https://launchpad.net/grackle

(One thing I notice about grackle now is that it's AGPL... that's going to
be unpleasant for some sites to run.  Perhaps we can change that or get some
changes added to the AGPL.)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120326/cb9bcd6e/attachment.pgp>