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

[Barry Warsaw]

On Mar 26, 2012, at 10:37 PM, David Jeske wrote:

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

See, stuff like this is *awesome*.

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

I really want to promote loose dependencies between major components, with
well-defined formal interfaces for them to interoperate.  Think "service
oriented architecture".  Unlike mm2, which tightly bundled the web ui and
archiver with the core engine, I think we can split these out into separate
components and yet ensure they'll all work together nicely.  Then we can
decide what might fall under the "GNU Mailman" umbrella, what will be our
default services, how we're going to bundle and release them, etc.  But others
will be able to make their own choices.

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

In a way, it's like the Python library ecosystem.  Most third party libraries
are independently developed and released, but pretty much work with (a
specific version of) Python.  Occasionally, some are borged into the Python
stdlib, which is both a blessing and a curse.

So in some sense, CSLA needn't become *the* Mailman archiver, but it should
definitely be *a* Mailman archiver.  Then you can make all the engineering and
design decisions you prefer, but with the confidence that it will Just Work
with Mailman 3.

(This of course also means you don't have to worry about boring stuff like
licensing, FSF copyright assignments, etc. etc.)

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

In some sense, yes.  Eventually, something will percolate to the top, have
technological decisions that we're comfortable with maintaining, compatible
licensing, etc. and then we can bring it under the Mailman umbrella.  But hey,
don't wait for that!  Make it work with the mm3 engine now and release early
and often.

(I clarified in a previous message that SMTP into the archiver is not a
requirement.  The implementation should be flexible enough to handle just
about any input mechanism you need.)

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

Or to support private archives, which is very definitely a feature goal IMO.
Even a 99% public site will likely have a few closed or limited access lists,
so I think an archiver will need to support use case.

-Barry