Terri Oda writes: > Writing individual pipelines may be trivial, but making a user interface > for managing said pipelines is non-trivial. Right now, our pipeline > management interface is "there's a text box in postorius that lets you > choose a pipeline. It's not even a dropdown, and you may be screwed if > you make a typo" which is obviously not how I want it when we > release. ;)
That's a more general issue (oh, I see you noticed that! :-), and I have no problem with doing something about it -- indeed, I'd be more than happy to (co-)mentor it because I just *love* custom Handlers. Here's what I would do: 1. Get the list of handlers active to the list. 2. Append the list of inactive handlers from Mailman/Handlers (the site's list, not the distributed handlers). 3. The UI is table with rows containing a checkbox for "active handler" (the row should be greyed out if it's inactive), an ordinal (numerical), and the handler name (gold star for popping up a tooltip with a detailed description/docstring on mouseover). 4. Users can either change the numbers (error checked for uniqueness), with a partial order on standard handlers -- if the partial order is violated (including a missing handler like "ToOutgoing") the user is warned; or (platinum star) drag the handlers into the order they like (with same checks on the partial order). > I see a potential project timeline going something like this: > > A. make a set of custom Mailman 3 Handlers for some well-known existing > anti-spam/anti-malware software. (Maybe 2-3 weeks of work here, finding > 2-4 reasonable pieces of software, setting them up, writing the > handlers, and testing them) One week for that work, it's all in the FAQ already I suspect. > B. make an interface in Postorius so list admins can > enable/disable/reorder these and any whitelisting happening within > mailman. This should involve making an interface in Postorius that > gives admins the ability to change the Pipeline being used, and will > likely involve a small amount of user testing to make sure said > interface doesn't have risk of disastrous results if the administrator > does the wrong thing. (Another 3-4 weeks of work including user > testing, unit tests, and documentation) You think the design above will take more than two days (one to learn how to do D&D to reorder a list) to code, and 4 to document and test? (I'm assuming Mailman2 kinds of pipeline APIs are already available. If new REST API is needed, OK, 3 weeks total.) > C. Figure out how to set up some sort of packager that can install > handlers + antispam software so that the site admin has an easy way to > set these up if requested. (Another 3-4 weeks of work, including testing > any scripts on a few different OSes and extensive documentation) OK, yes, getting PyPI down for the Handlers themselves (while these *could* be delivered with Mailman, I think it would be more valuable to have a standard PyPI delivery protocol for 3rd party Handlers) will likely take that much time, and indeed one needs to deal with OS PMS. > Do feel free to disagree with me, of course, Stephen. I am indeed a curmudgeon about the antispam stuff. I don't think the first release of Mailman 3 should contain an attractive nuisance like serious antispam in Mailman (vs antispam in the MTA). I'll try to keep such negative thinking to one paragraph per post, though. :-) > Or complain that I'm using the lure of antispam to get someone > solve my user interface for pipelines problem, which I totally > am. ;) While I do think that an initial implementation is probably a total of about 2 weeks worth of work, I suspect that one could riff on the theme (hi, Barry, like that metaphor?) for a couple more weeks, and robust disaster recovery (saving off the old pipeline and restoring looks simple enough, but Mr. Murphy is lurking, I'm sure -- in particular, if we're going to allow through-the-web pipelines, we need to guarantee that received mail will not get lost if the pipeline is horked) could account for a couple more weeks. _______________________________________________ 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
