On Mar 27, 2012 5:32 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

If the archiver/web UI is going to be distributed *with* Mailman, Barry would probably prefer Storm + Django because that's what Mailman/Protorius (core and admin web UI, resp.) are using. But I imagine that's negotiable as long as everything is free software.

I'll take a look at the Mailman2/3 code and see what the pattern looks like.

Storm-ORM looks like it allows any primary key so that's good. From a quick glance it looks very similar to the Clearsilver-odb-orm in syntax and function. My primary beef with django-orm (last time I looked at it) was it requiring a unique-id primary key which is pretty poor for multi-row fetch performance design.

Clearsilver templating has a slightly more aggressive enforcement of 'no code in template' than django, because it has an explicit intermediate dataset called HDF (it doesn't allow access to arbitrary python lists, structs, classes, and methods). This allows it to work from any language (not just python), and makes the binding from the ORM a bit more explicit. However, it also means it's a c-module, and I can see the advantage to keeping c-compile dependencies to a minimum.

...

...

AIUI, the current philosophy is that

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

Sure, but you're already running a sufficient server, namely your MTA.

Gotcha. I thought you were saying Mailman wanted the archiver to be a long-running server accepting SMTP/LMTP on a socket.

I normally manage the archive queue with the MTA, and have it launch the archive-injestor for each message.. (or for higher volume applications, long-running injester on a Maildir).. which sounds like what you're saying..

After I finish some quick cleanup and UI changes to CSLA I want to do, I'll take a look at MM2/3 and see if I have better questions once I'm informed.

Thanks for the great overview.