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