On Jul 13, 2011, at 04:51 PM, Paul Wise wrote: >By bounce I meant SMTP-time rejection, sounds like the LMTP stuff >provides that (and mailman 2 doesn't use that IIRC).
Correct. >Temporarily failing lists were not an objective. Cool, I think we're agreed on that. >The design of list objects seems to be heavily similar to how the UI >is in mailman 2, I think it should be much more generic. > >For example: > >In the web UI turning on emergency moderation should set the first >item in the receive pipeline to a hold() function. > >Disabling a list would set the first item in the receive pipeline to >reject_disabled, set the first item in the subscription pipeline to >reject_disabled, set the first item in the settings pipeline to >admin_read_only etc. This isn't exactly how MM3 works. In MM3, the incoming queue sends the message through a chain, where each link has a rule and an action. An action can be something like "jump to the `hold` chain", which is in fact exactly what happens in the default built-in chain: src/mailman/chains/builtin.py: _link_descriptions = ( ('approved', LinkAction.jump, 'accept'), ('emergency', LinkAction.jump, 'hold'), ... There really aren't "subscription" or "settings" pipelines, and I'm not sure they're the right way to implement what you have in mind. >List objects should be flexible to support different kinds of lists, >but the UI should hide most of that behind simple labels like "retired >list", "public list", "private list" and the "emergency moderation" >button. MM3 has list styles, which are composeable and extensible. A style is only applied at list creation time though. >PS: Is there a Mailman UI yet? The link on the Mailman branches wiki >page points to one with only one commit in it and no working code. I think we're still waiting for Florian and the GSoC students to propose branch merges into lp:mailmanweb. >PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm >thinking configuration filenames, data directories etc should be named >mailman3 instead of mailman. Maybe. I'd really like to not do that if it can be avoided. For example, the configuration system is so different I can't see how there would be much collision. The data directories, possibly, but I also think there are enough knobs to allow site admins or vendor packagers to set things up with the proper defaults. I don't think there will be any collisions on command line program names. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9