1 files changed, 93 insertions, 2 deletions

diff --git a/TODO b/TODO
index 38d3cb7ca..088485ca9 100644
--- a/TODO
+++ b/TODO
@@ -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...