Re: [Mailman-Developers] Requirements for a new archiver
On Wed, 29 Oct 2003 23:01:14 -0500 Barry Warsaw <barry@python.org> wrote:
On Wed, 2003-10-29 at 16:54, J C Lawrence wrote:
Aye, picking the right interface abstractions is key.
Right on.
I'm still debating if I can run down there on the 8th. I'd love to go to EuroQuest, but I also really need to be in Providence on the 7th, and back at work on the 9th. Aaaarrrgh. _IF_ I can make it we must go hit a pub with whiteboards in hand.
Sorry for no earlier reply on this BTW, I'm in drowning eyeballs mode.
...as well as implement a bulk mailer to eliminate the need for an outgoing mail server.
Eeeek! I trust this would be for immediate handoff to a "real" MTA versus handling final delivery directly? Quite the Pandora's box if not.
Mailman v2.1 has a plugin layer for the membership roster. Its not a fully mature interface, but there are LDAP and SQL adaptors in the wild.
This interface was largely bolted on, so it's clumsy. Mailman 3 will be defined by interfaces from the start.
<nod>
BTW Whatever happened to Michel Pelletier's interfaces PEP? I see the draft, and I see signs that something got done, but not what...
Oh yeah, and just to keep Nigel Metheringham hopping:
Mailman just doesn't have enough configuration options.
Heh. That's another issue.
Last I heard Nigel was still running screaming into the hills.
I'm sure Mailman 3 will grow many more configuration options. The trick is making them manageable (and mostly ignorable -- i.e. the defaults Usually Work out of the box).
<nod>
I've been experimenting with ideas for list styles which will make list admins lives easier I think, without reducing the flexibility for experts.
Aye, that's something the Plone folk have been digging at with some success: a base library of waffle-stomp configuration patterns. I'm not sure for Mailman if we want just a picklist, or a very simple wizard.
I suspect something more akin to the very brief Q&A wizard at Creative Commons for choosing a license type may be more effective and interesting than a picklist:
http://creativecommons.org/license/
Very simple, very general, covers the basic cases, hides all the ugly stuff and picks sane defaults. It becomes even more interesting if site admins can tailor the configs for the basic cases.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On Wed, 2003-10-29 at 23:17, J C Lawrence wrote:
I'm still debating if I can run down there on the 8th. I'd love to go to EuroQuest, but I also really need to be in Providence on the 7th, and back at work on the 9th. Aaaarrrgh. _IF_ I can make it we must go hit a pub with whiteboards in hand.
Sounds great. Bring a laptop and we'll bang out some code (anyone else up for a mini-Mailman-3 sprint at my house? :). I'll probably be heading to Fedex Field on the 9th for a 'Skins game, so the 8th would be perfect.
...as well as implement a bulk mailer to eliminate the need for an outgoing mail server.
Eeeek! I trust this would be for immediate handoff to a "real" MTA versus handling final delivery directly? Quite the Pandora's box if not.
Yep, which makes me nervous, but which does have a certain standalone-ability appeal. I don't want to write it off, and of course, we'll have an interface for this so the first (only?) implementation will be MTA hand-off.
BTW Whatever happened to Michel Pelletier's interfaces PEP? I see the draft, and I see signs that something got done, but not what...
Dead in the water AFAIK. But there are lots of folks using a more formal interface system for Python applications, such as for Zope3. Just writing the interface down, with good docstrings, goes a long way.
Last I heard Nigel was still running screaming into the hills.
Hey, I love Exim -- Greg's done some very cool stuff with it on mail.{python,zope}.org. But man, I find it hard to track down just the right knob I need to tweak. :)
Aye, that's something the Plone folk have been digging at with some success: a base library of waffle-stomp configuration patterns. I'm not sure for Mailman if we want just a picklist, or a very simple wizard.
I haven't even thought about how to surface it in the u/i -- it's mostly machinery right now. But yeah, a wizard is just the ticket, at least for canned styles (which again, will solve 80% of the problem).
Which reminds me -- I'm really hoping we can get some web u/i jockies and CSS geeks in to eventually make things real purty. Dammit Jim, I'm a musician, not a graphic artist. :)
-Barry
On Thursday 30 October 2003 05:17, J C Lawrence wrote:
...as well as implement a bulk mailer to eliminate the need for an outgoing mail server.
Eeeek! I trust this would be for immediate handoff to a "real" MTA versus handling final delivery directly? Quite the Pandora's box if not.
I believe the best approach is to cover all options:
- for test installations that work out of the box (people who don't care of performance, or don't care if 10% of messages gets refused because of broken MTAs out there)
- for real production installations (where admins are smart/skilled and they know how to plug a real MTA, a real web server, and so on.)
- for real installations on limited platforms (e.g. on a web server which
doesn't support proxy rules but only has CGI)
Naturally, the main underlying interface should be the "right" one, e.g. the
one which gets the best stability and performance (plugging into a real MTA
for sending/receiving email, proxy on a web server, etc.) and then we can
just add some script to glue other solutions.
Some example supposing we have built-in machinery for - direct web serving
- smtp sender
- pop3 poller
A real installation will receive messages via pipe (like we do now) or LMTP or SMTP (from a real MTA fronting us) and will send them via smtpdirect to a real MTA (like we do now). The web interface will be served directly but fronted by a real web server in reverse proxy configuration.
A real installation with a limited web server (no proxy rules) will be the same as above but there will be a proxy CGI that when invoked will connect to our internal web server (I know, this is slow, but CGI alone is slow anyway).
A real installation heavily skinned will be the same as above but the web GUI will be built by a 3rd party talking with mailman over XMLRPC, just to exchange data and commands.
A test installation (or a poor man's installation) will fetch messages from pop3 mailboxes (polling! I can hear you scream while you read this!) and send them directly to the internet (no real MTA involved) and will probably serve web pages directly, controlling port 80 (no real web server involved).
Ideally there should be a wizard to choose among the available classes of installation, and then every other knob should be available TTW.
-- Adde parvum parvo magnus acervus erit -- Ovidio
participants (3)
-
Barry Warsaw -
J C Lawrence -
Simone Piunno