diff options
| -rw-r--r-- | TODO | 95 |
1 files changed, 93 insertions, 2 deletions
@@ -1,8 +1,99 @@ -$Revision: 403 $ +TODO for mailman 1.0b2 (TODO $Revision: 451 $, $Date: 1998-04-13 21:15:48 +0100 (Mon, 13 Apr 1998) $) This document is by no means up to date, sorry. -klm, $Date: 1998-04-10 01:06:50 +0100 (Fri, 10 Apr 1998) $ +For after v 1.0b2: +------------ +Pending bugs +------------ + - Mime digests a bit feeble - postings containing mime attachments + not properly handled + - Bounce processing + - Turning off bounce processing doesn't? + - Turning on non-member-post exclusion doesn't + - More generally mm_utils.AddressesMatch() needs to be really + thought out. For instance, klm@python.org vs klm@acm.org should + be seen as different, but klm@parrot.python.org and + klm@larch.python.org and klm@python.org should probably be seen + as the same. There may be more criteria... + - Bounces of the confirmation notices sent to people attempting + web-based subscriptions are, necessarily, directed (via reply-to + header) to maillist-request addr, and get mishandled there as + unrecognized requests. Not sure how to solve this one short of + recognizing bad subscriber addrs before sending out the notice. +------------------------------- +Pending Developments and Issues +------------------------------- + Some modest Pending Refinements: + - Use re module everywhere instead of regexp and regsub. + - Implement a reasonable administrivia filter for lists (but less + likely to misfire than majordomo's) (administrivia is, eg, + unsubscribe request mistakenly sent to list posting addr) + - Refine any unqualified exception guards to specify target exceptions. + - Turn standard mailman exceptions into class exceptions. + - Implement cookies (with moderate lifetimes) for user and admin passwords. + - Unravel edit-options functionality from cgi/subscribe script - give + edit-options a script of its own. (Not imperative, maybe when the + bigger project of implementing member profiles is done.) + - Relax constraint that everything be installed in /home/mailman. + (I'll probably do this for the next release. We can probably use + relative paths for most things, particularly the routine sys.path + setting in all the python code, and possibly for the wrappers.) + - Foolproof list deletion (bin/rmlist) a bit by asking for password + (and have list admin or site password work). + - Should member deletion be confirmed with email? + - Submission of edited user options should return to edit-options + page, like admin options pages do. + - People mass subscribed on admin form should not require approval, + even for closed-subscribe lists. +Some bigger Pending Projects + - User and Admin Guides - HOWTOs + - Developers guide - documentation + - Implement email interface to admin commands. + - Implement a 'which' mailcmd. (Probably not hard! May be good intro + project for someone wading into mailman development.) + - Put the admin interface and other things like private subscriber rosters + *behind* passwords, like the private archives are. Eg, instead of + putting the password box on the listinfo form, have it always be just + a regular link to the roster, but then the roster page would be a + password page if the roster is private and there's no cookie for it. + - Generalize and refine admindb so that pending bounces, + subscriptions, etc are stored in the filesystem, nicely catalogued, + and the interfaces for handling them (eg, admindb) shows succinct + summaries, with links to see the entire things. (I may work on this.) + - Develop subscription mechanisms so real confirmation happens, and + use that as basis for option to change existing subscription + delivery address. (Scott cotton is working on this.) + - Deliver by connect to SMTP 25 instead of sendmail. (I'm checking + in modules/smtplib.py module john's played with some.) + - Robustify aliases handling to not just append entries if they + already exist, and ideally, edit existing ones if they need to change. + - Implement a real admin/membership-management section, that includes + includes hidden subscribers, provides easy perusal and changing of + all members (including concealed members) status, including + disabling or removal from list. + - Implement some automated validation of installation - check for + obvious problems with options settings, file access permissions, + sendmail hookup, etc. + ? Have an implicit list-managers list for every site, which includes + all the list managers? + - Make listinfo page static, regenerated every time admin options are + changed. This will speed up and reduce load for listinfo page + loading. +More Fundamental, or just more bigger:), Pending Projects + - Refine locking to only necessary sections, so there's less room for + unnecessary contention. + - Implement the system as a persistent server. (John's planning to + do this.) + - Implement member profiles, using a class. For name, organization, + description, etc, and defaults options settings. The lists, + themselves, could still have copies of the specific passwords and + the compact bitmaps (for the sake of efficiency) for list-specific + options like digest/nondigest, but the user could set their default + choices - delivery address, password, delivery mode - in their + profile. + +=================================================================== For v .96: o Add more bounce patterns.... o Confirmation when you change anything... |