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

[David Jeske]

> So if you have already developed some stuff, I
> certainly would love to see you put it on the table
> as a candidate for the Mailman 3 default
> archive web UI.

Yes. My CSLA code is on the table for MM2 or 3. It's python, and it's BSD.
More than that, if you folks want it, I'm happy to retool/rewrite it as
needed to make it suitable. (it has lots of great features, but i havn't
touched it in a long time and it could be better) I'll put up a demo of the
mailman list in CSLA tomorrow so folks can check it out.

I also have "some experience" with this space, and by that I mean
mountainous-experience. I coded/managed/architected several versions of
eGroups/Yahoo Groups and Google Groups, including the listprocessor, schema
design, and a few different python mail-to-html formatters. I also wrote my
own personal gmail-like web-mailer in python, which someday I'll get around
to open-sourcing.

Can you share something about dependency philosophy (besides licensing) in
Mailman?

Currently CSLA uses Clearsilver templating (BSD c-module) and sqlite
(public domain) storage.. both of which can be included directly as source
to make installation easy, but they are both c-modules.

I'm quite fond of the Clearsilver orm-to-templates toolchain, which is in
use for lots of big sites. However, I also recognize it's not that popular
in the python commmunity, mostly because we don't promote it, but also
because the template processor c-module (for performance) instead of pure
python.

If it's necessary I could convert CSLA to use django templates, though they
have a nasty design/performance problem with the orm that I think would
prevent me from using it (unless I fixed it).

I'm not a fan of javascript client-side rendering because of the generally
poor performance, poor mobile compatibility, and lack of benefit for this
kind of application.

> Doing a *better* job of formatting HTML (than pipermail) is easy.
> Doing a  *good* job is going to be relatively hard, though.

Isn't that the truth.

Back at Egroups there was a time where it seems like we used to tweak the
formatter almost daily. Deciding when preformatting is necessary vs harmful
is a real pain.

My CSLA python code has a fairly stable msg-to-html formatter that I've
been happy with for a long time. It does very aggressive automatic
repetitive text eliding for thread-display, so you can read many messages
in a thread in a single page without massive quote pileup. View-source is
provided for the unfortunate case where it does something bad.

> AIUI, the current philosophy is that
>
> (1) the communication from Mailman to the archivers
> will be via LMTP/SMTP, including a Mailman-specific
> header to identify the message's permalink (currently
> the SHA1 hash of the message ID in BASE32
> format, IIRC); and

Using SMTP for an included archiver would require it be a long running
server instead of merely a handler.

Are we talking about third-party-site archivers here?

> (2) the summary, search, and retrieval UI will be a
> separate application from Mailman per se, which will
> communicate with Mailman via the REST API for
> authentication and user configuration purposes.

That makes sense...

CSLA doesn't currently have any concept server-auth. The only stateful
features it has are view-preferences and read-state, neither of which are
important enough to require a password. It uses a password-less system
which uses cookies for prefs and a 'read state userid' which a user can
manually set if they want. I like it, because it doesn't require login to
get some basic browsing prefs and features.

Hooking up an auth system would be necessary for some of the editing ideas
in the document I read, or to allow online posting.