7 files changed, 8 insertions, 730 deletions

diff --git a/doc/IPC7/IPC7.ppt b/doc/IPC7/IPC7.ppt
deleted file mode 100755
index 0c7bf8d12..000000000
--- a/doc/IPC7/IPC7.ppt
+++ /dev/null
diff --git a/doc/IPC7/README b/doc/IPC7/README
new file mode 100644
index 000000000..835ff71a2
--- /dev/null
+++ b/doc/IPC7/README
@@ -0,0 +1,8 @@
+The file ipc7.doc contains the MS Word version of the Mailman paper
+presented by Ken Manheimer at the 7th International Python Conference,
+held in Houston TX, November 10-13, 1998.
+
+The file ipc7.ppt contains the MS PowerPoint slides Ken used in his
+presentation.
+
+[ipc7.doc.gz and ipc7.ppt.gz are compressed with GNU gzip]
diff --git a/doc/IPC7/arch.txt b/doc/IPC7/arch.txt
deleted file mode 100644
index 5bc029e04..000000000
--- a/doc/IPC7/arch.txt
+++ /dev/null
@@ -1,178 +0,0 @@
-Architecture
-============
-
-Core Classes
-============
-
-The Mailman software consisted of a core set of Python classes,
-oriented around the specifically supported tasks.  For example, there
-is a Deliverer class which has primary responsibility for delivering
-messages of various kinds to users.  There are also classes that
-handle message bounces, formatting of the Web pages, list
-administration, etc.  These are covered in more detail below.  These
-task-oriented classes are composed into a higher-level MailList class
-via multiple inheritance.  These classes live inside individual
-modules in a Python package directory.
-
-Whenever access to a specific list is made, either via the Web forms,
-email commands, or interactively, an instance of the MailList class
-must be instantiated.  The MailList class adds to the mixin base
-classes methods to extract list specific information such as important
-URLs or email addresses.  It coordinates the initialization of the
-mixin classes, handles saving and loading a mailing list's persistent
-data, creating new lists, and managing file system locks.  The
-MailList class also manages the posting of messages to the list,
-although this might rightly be migrated to a separate base class.
-Most importantly, the MailList class coordinates the set of
-configuration options that are exposed to the Web user, although some
-of the mixin classes do actually define additional option categories
-(more on this below).
-
-The task-oriented base class perform all the other functions that can
-be invoked on a mailing list object.  The following base classes
-currently exist:
-
-MailCommandHandler:
-    This class implements the parsing and execution of Majordomo-style 
-    commands embedded in email to -request addresses.  Although most
-    users will interact with mailing lists directly through the Web
-    interface, for compatibility, commands can be injected into the
-    Mailman system via email, and where appropriate, the commands have 
-    the same syntax and semantics as the corresponding Majordomo
-    commands.
-
-HTMLFormatter:
-    This class is used to generate list-specific HTML for presentation
-    via the Web interface.  Primarily, it uses a widget library also
-    included in Mailman.  Together this class and library serves a
-    purpose very similar to [XXX ref: Robin's or Digicool's
-    DocumentFormatter, not sure]
-
-Deliverer:
-    It is this class's task to deliver email messages to list member
-    and individual users.  It handles such tasks as sending post and
-    subscription acknowledgements, and mailing users their passwords
-    (either through the periodic reminder system, or when explicitly
-    told to via the user specific Web interface).
-
-ListAdmin:
-    This class manages the queuing and notification of requests to the 
-    Mailman system that are held for approval.  For example, it may be 
-    that all subscriptions must be approved by the list owner.  In
-    this case the message is held and managed by the ListAdmin class.
-    This class handles posting and subscription holds, as well as the
-    sending of refusal messagse.
-
-Archiver:
-    This class handles the archiving of messages posted to a list.
-    Mailing lists can have public or private archives and this class
-    places the posted message in the appropriate location.  This class 
-    also interfaces with external Hypertext archivers such as Andrew
-    Kuchling's Pipermail [XXX need ref] which is bundled with Mailman.
-
-Digester:
-    Members can receive posting immediately, or they can request to
-    have periodic digests of the discussions email to them instead.
-    This is a per-user settable option, although there is some
-    override available to list owners.  The Digester class manages
-    digest creation options (such as whether digests will be sent as
-    MIME, what the digest size thresholds should be).  It is
-    responsible for collecting messages during the posting process,
-    and manages the creating and sending of the digests when the time
-    comes.
-
-SecurityManager:
-    This class primarily verifies authorization passwords for the site 
-    administrator, list administrators, and users.  It also performs
-    the task of sanitizing posting which contain the Majordomo-style
-    approval headers.
-
-Bouncer:
-    Mailman contains some sophisticated email bounce handling
-    facilities, which allow it to do things like disable or remove
-    users from lists when their addresses receive excessive bounces.
-    The Bouncer class manages these facilities and the options that
-    control them.
-
-GatewayManager:
-    This class handles optional email-to-Usenet gateways for mailing
-    lists.
-
-
-Interfacing to the Outside World
-================================
-
-The MailList class provides the central access for doing anything with 
-a mailing list.  This class, as well as other utility functions are
-combined and used by scripts which provide interfaces to the Web via
-CGI, or commands executed by the mail system.  The core Mailman system 
-is designed to also be accessed through an interactive Python
-interpreter, which facilitates testing and development.
-
-[[XXX Ken wants to tone this down]]
-
-The CGI scripts in turn are started by a common driver script, which
-wraps all the functionality in flexible error handling code.  This is
-so that when a system error occurs, a detailed traceback, along with a 
-dump of the current environment variables, are displayed both on the
-Web browser (so the user has better feedback on what when wrong), and
-in a log file on the Mailman system.  These two forms of error
-feedback help ensure that problems can be more quickly traced and
-fixed.  Finally, there are C wrapper programs that invoke the driver
-script from CGI or sendmail.  The wrapper programs are used for added
-security.
-
-Mix-in Structure Benefits
-=========================
-
-The mix-in structure of the system has a number of important benefits.
-First, the task-orientation of the base classes allows for new
-functionality to be easily added.  For example, when an email to
-Usenet news gateway was added, it was a fairly simple matter to write
-the GatewayManager class (described above) that handled this task, and
-add that to the list of MailList base classes.  Second, since all the
-data is list-centric, almost everything that can be done to a list is
-available as methods on the MailList class.  Using mix-in classes here
-simplifies the passing of arguments, and reduces the amount of the
-interface that has to be duplicated from base classes to the derived
-class.
-
-[[XXX Ken may wish to move this]]
-
-There are some downsides to the mix-in architecture, but they are
-relatively minor.  Using mixins, with many cross class method calls,
-leads to a lack of compartmentalization increasing maintenance
-burdens.  It is more difficult to unit test each class.  It can also
-be difficult to figure out when reading the code, in which of the base
-classes a particular method is implemented.  Using delegation would
-ease this latter burden because the target of the method would always
-be discernible.  Also, initialization of the MailList class happens in
-two phases and it is sometimes difficult to coordinate initialization
-correctly with all the base classes.  All in all though, using
-multiple inheritance is a larger benefit.
-
-List Specific Persistent Data Store
-===================================
-
-The persistent data for each list is maintained as a marshalled
-dictionary which is saved in a file.  This file is read from the
-filesystem and the data attributes are unmarshalled when a specific
-list is instantiated.  The elements of the dictionary are actually
-taken from the attributes of the MailList instances (attributes whose
-name begins with an underscore are filtered out).  [[XXX Ken wants to
-reveal this later]] Thus as new option-controlling attributes are
-added, they can be automatically included in the list databases.
-
-Configuration Options
-=====================
-
-Each configuration option supported by Mailman is described in the
-MailList class as a tuple of information, containing: the name of the
-option (which also names the instance attribute), the data type
-(primarily describing the Web GUI widget for editing the option),
-option value ranges or other parameters to the widget, and short
-description and a longer description.  These tuples are gathered
-together into a dictionary with the keys being the high-level Mailman
-configuration categories.  Again, this makes it easy to add new
-options and to integrate new options in the mixin classes.
-
diff --git a/doc/IPC7/draft b/doc/IPC7/draft
deleted file mode 100644
index 2c4e82f87..000000000
--- a/doc/IPC7/draft
+++ /dev/null
@@ -1,552 +0,0 @@
-      Mailman - An Extensible Mailing List Manager using Python
-      =========================================================
-
-Ken Manheimer
-Corporation for National Research Initiatives
-
-Barry Warsaw
-Corporation for National Research Initiatives
-
-John Viega
-Reliable Software Technologies
-
-			       Abstract
-			       ========
-
-The explosive growth of Internet communities, and the core role that
-email plays in it, calls for a Mailing List Management (MLM) system
-which can adapt to, and even foster, new forms of community
-organization as they emerge.  A new MLM, Mailman, is well suited to
-such evolution because it is designed to be versatile and extensible.
-One factor contributing to these strengths is its implementation in
-Python.
-
-In this paper we will look at various aspects of Mailman's
-extensibility.  We will consider how the system's design and how
-features of its implementation language, Python, factor into that
-extensibility.
-
-			     Introduction
-			     ============
-
-			    What is Mailman?
-
-Mailman is a Mailing List Management system, like Majordomo and
-Smartmail, used to manage email redistribution lists.  Mailman gives
-each mailing list a Web page, and allows users to subscribe,
-unsubscribe, etc. over the Web.  List managers can administer their
-lists entirely from the Web.  Mailman also integrates most things
-people want to do with mailing lists, including archiving, mail <->
-news gateways, and so on.
-
-Mailman was originally developed by John Viega.  Ken Manheimer picked
-up the ball to bring Mailman to 1.0.  Currently, Mailman development
-is a group effort, led by John Viega, Ken Manheimer and Barry Warsaw.
-Mailman has been designated by the Free Software Foundation as the GNU
-Mailing List Manager.
-
-See [LO "Mailman"] for more details on the system, and visit the [MD
-"Mailman-developers"] mailing list if you're interested in joining the
-Mailman development community.
-
-
-			  Why Extensibility?
-
-From the early days of the ARPAnet to today, email and Mailing List
-Management systems have played a crucial role in the formation and
-conduct of communities on the Internet.  With the profound dynamicism
-of the Internet, the infrastructures by which it organizes are
-continually evolving.  Over time, the rapidly increasing scale and the
-advent of improved and new strategies for organization of Internet
-communities demand continuing development of the mechanisms supporting
-them.  New and different approaches may take up some types of the
-traffic, as Usenet News has, but email, as a medium, has proven to be
-particularly versatile and enduring.  A good MLM will help foster the
-evolution of the Internet communities, by growing with them.
-
-Another reason for extensibility's importance has to do with a core
-constituency of mailing list users - the mailing list administrators.
-These administrators are typically near enough to the end-users to get
-clear impressions of their needs.  Also, they commonly are savvy
-enough, technically, to be able to implement improvements to
-accommodate those needs - provided the system doesn't present too high
-a threshold of comprehension.  Here is a prime opportunity for
-exploiting the Bazaar-style of open-software development ["The
-Cathedral and The Bazaar"], enabling the managers of the medium,
-themselves, to guide its development, enabling results more quickly
-and closely tailored to the needs of the user community.
-
-Finally, most aspects of an MLM do not require the kind of speed
-optimizations which force change-impeding hardening of system.
-Performance critical aspects, like mail delivery to large numbers of
-users, is generally the purview of the underlying Mail Transport
-Agents (MTAs), not the MLM.  Large capacities can impose some
-specialized performance demands on the MLM, of course.  The specialty
-of those demands, however, enables isolating the optimizations to
-select components, and Python's compiled-language extensibility
-enables hardening those specific components as needed, isolating the
-rigidity to the particular subsystems that need it.  At this point we
-don't see hardening any components in this fashion, but we don't know
-what the future (or potential growth of Mailman's use) will bring.
-
-			     Why Python?
-
-Python is particularly well suited to implementing an extensive and
-changing system.  Its combination of clean syntax and cogent semantics
-aids the programmer, all the more in the process of changing existing
-code.  It is dynamic in many respects, enabling interaction with and
-programmatic handling of just about everything in the language.  By
-satisfying the needs of prototyping and rapid development, as well as
-those of general programming, it can be seen to foster "continuous
-development", where a system continues to grow and evolve to
-accommodate a changing world.
-
-	       A Broad Overview of Mailman's Structure
-	       =======================================
-
-The core of the Mailman system is the MailList object, a class
-instance which represents individual mailing lists at the site.  The
-MailList class is composed by multiple inheritance from a number of
-task-oriented component classes, as mixins.  The task oriented
-components contain the methods, variable declarations, and
-initializations related to the functionality of a particular
-subsystem; for example, that of the delivery mechanism or of the
-emailed-commands handler.
-
-The code directly in the MailList class is responsible for
-coordination of the mixin classes initialization, central
-identification of the specific mailing list, creation of new mailing lists,
-and management of mailing lists persistent data and locking.  The internal
-MailList object code also handles the very top level of subscriptions
-and message posting, but the task-oriented base classes are
-responsible for the underpinnings of that and all the other functions
-of the mailing list object.  The following base classes currently
-exist:
-
-MailCommandHandler:
-    This class implements the parsing and execution of Majordomo-style 
-    commands embedded in email to -request addresses.  Although users
-    more typically interact with mailing lists directly through the
-    Web interface, for compatibility, user commands can be issued via
-    email.  Where appropriate, the commands have the same syntax and
-    semantics as the corresponding Majordomo commands.
-
-HTMLFormatter:
-    This class is used to generate list-specific HTML for presentation
-    via the World Wide Web interface.  Primarily, it uses a widget
-    library also included in Mailman.  Together this class and library
-    serves a purpose very similar to that of Robin Friedrich's HTMLgen
-    [RF "HTMLgen"] and Digital Creations, L.C. [DC "DocumentFormatter"].
-    (These alternatives were not real candidates during the early
-    stages of mailman's development.)
-
-Deliverer:
-    This class conducts delivery of any of the email associated with a
-    mailing list.  This includes membership delivery of postings,
-    subscription acknowledgments, announcements to the list
-    administrator about list creation, list business pending approval,
-    subscriber notices regarding their passwords, and myriad other
-    things.  Email is used for a lot of things by a mailing list
-    system, even one with a comprehensive Web interface
-
-ListAdmin:
-    This class manages the queuing and notification of mailing list
-    submissions - postings and subscriptions requests - that require
-    administrator decision (approval or rejection).  For example, a
-    list may be set to require administrator approval for any
-    postings, or a posting may be held due to triggering a filter
-    intended to catch undesired commercial messages (can you say
-    spam?).
-
-Archiver:
-    This class handles the archival of posted messages.  Mailman
-    mailing lists can have public or private archives, and this class
-    places the posted message in the appropriate location.  It also
-    also interfaces with external Hypertext archivers such as Andrew
-    Kuchling's Pipermail [AMK Pipermail], which is bundled with
-    Mailman.
-
-Digester:
-    Mailing list members can receive posting immediately, or they can
-    opt to have cumulative "digests" of the list traffic sent to them
-    periodically.  This class manages accumulation of the digests,
-    formulation of the plain and MIME formats (when there are
-    subscribers to the respective types), and dispatching of the
-    digests to the respective subscribers.
-
-SecurityManager:
-    This class primarily verifies authorization passwords for the site 
-    administrator, list administrators, and users.  It also performs
-    the task of sanitizing the Majordomo-style approval passwords from 
-    the headers of administrator approvals submitted via email.
-
-Bouncer:
-    Mailman catches email delivery bounce notices, and accumulates
-    tallies of bounce scores for the mailing list members.  For scores
-    that exceed designated thresholds within designated timeout
-    conditions, the bouncer triggers list-prescribed actions,
-    including disabling of mail delivery or, if set by the list
-    administrator, unsubscription of the member from the list.
-
-GatewayManager:
-    This class handles optional email-to-Usenet gateways for mailing
-    lists.
-
-	      A Selective Tour of Mailman's Versatility
-	      =========================================
-
-	  Programming and Interacting With MailList Objects
-
-Mailman's central structure is the MailList instance objects, which
-represent individual mailing lists.  They are designed to be easily
-instantiated by external programs, providing a single, easy to handle
-package for access to almost all mailing list functionality.  They
-constitute a tidy, self-contained API for articulation of mailing
-lists from programs, and also for interaction, using the interactive
-Python interpreter shell.
-
-Managing their own locks of their lists, the objects can be used
-simultaneously from many processes without conflict.  Programs
-manipulating MailList instances run under CGI for Web interfaces, or
-via command-pipe email aliases for email interfaces.  Cron scripts
-instantiate the appropriate MailList instance and use it to do the
-cron job.  MailList object based scripts also are used to automate any
-routine procedures, such as conversion of subscriber lists from
-established Majordomo mailing lists.
-
-Interactive sessions with MailList instances provides an eminently
-useful development and debugging tool.  Maillist objects are easy to
-instantiate - all that's necessary is inclusion of the Mailman package
-dir on the PYTHONPATH, and knowledge of the right module to import.
-With interactive instantiation, we are able to exercise and test
-isolated subsystems, as well as the behavior of the MailList as a
-whole, and we can employ exploratory tools, like the Python debugger,
-along the way.
-
-We can also use interactive sessions to do mailing list "surgery" - to
-operate the MailList in ways not provided for in existing 
-scripts.  Using a utility function, Utils.map_maillists(), we can
-apply arbitrary functions to all or to selected Mailman mailing lists
-at the site.  This enables us to do wholesale conversions of the
-MailLists to accommodate, for instance, changes in the address of the
-site, or to search for particular members of any of the mailing lists
-and then do some processing on their subscriptions.
-
-	       MailList Object Composed via Inheritance
-		    from Task-Oriented Components
-
-Composing the MailList class using multiple inheritance makes it easy
-to share the component class methods and data throughout the MailList
-object.  It avoids the need to explicitly identify and pass around
-delegate instances in order to use those component's data and methods.
-Having all the methods and data inhabit the namespace of the primary
-MailList instance can lead to inadvertent name collisions.  However,
-we feel that the system would have to get much bigger before that
-would become a practical concern - and at that point we could use
-naming conventions to prevent the collisions, while still enjoying the
-easy sharing.  Use of multiple inheritance provides this direct
-sharing, along with organization of the system into distinct,
-conceptually motivated modules, easing debugging and development.
-
-New major modules are still being added as task-specific mixin
-classes, and the process is exceptionally uncomplicated.  For
-instance, as of this writing one of the primary authors added
-bidirectional mail/news gatewaying capability to Mailman.  This module
-required knowledge of some boilerplate structure, and only minor
-changes to existing modules, providing a major functionality with
-almost plugin-style ease.
-
-		  MailList Object State Persistence
-	   Exploits Introspection And Uncomplicated Sharing
-
-This direct sharing also simplifies the MailList object's persistence
-mechanism.  By identifying its own data members via self.__dict__, the
-MailList object's persistence mechanism saves and restores MailList
-state using a marshal.  (Members that should not be saved are
-distinguished with a leading "_" underscore.)  This exploits Python's
-introspection capabilities, as well as a standard, simple persistent
-storage facility.  (The higher level standard persistent storage
-mechanism, pickle, would do more work than we want or need, so we were
-able to avoid its overhead.)  As with sharing in the first place, the
-arrangement is uncomplicated, easing approach and acquaintance by
-newcomers.
-
-Logging Mechanism
-
-Most of the common interactions with MailList objects are triggered
-remotely - via the Web or email - or from periodically firing cron
-jobs.  The lack of an operator or a console can make system failures
-in these contexts hard to trace.  Of course, every program should be
-perfect (:-), or at least fail gracefully.  However, when programming
-in an environment where change is frequent, we need to provide some
-defensive mechanisms which aid the capture of the errors that
-inevitably slip by.  Mailman's logging mechanism provides that
-coverage.
-
-Reliable logging is also key for tracking the occurrence of common
-events that otherwise take place "behind the scenes".  This can
-include mailing list subscription activity, automated change of
-subscriptions due to delivery failures, and so forth.  It also is
-useful to be able to use "flag-printing" debugging, even when stdout
-does not go anywhere useful - e.g., when running under CGI, or in
-disconnected forked processes, or via email.
-
-The crux of the Mailman logging scheme is a Logger class which job is
-to direct messages to log files while minimizing the disruption when
-the log files are inaccessible.  Logger instances obey the
-conventional Python file-like object interface protocol.  Thus, they
-can be used to write messages like standard file objects would be.  In
-addition, logger objects themselves are defensive about access to
-their log files, attempting to open them "lazily", and avoiding
-interrupting operations if they are unable to access the log files,
-trying alternative reporting avenues, instead.
-
-Logger objects can also be substituted for standard output streams
-like sys.stderr and sys.stdout, enabling, for instance, blanket
-capture of error tracebacks from within the modules where they occur.
-Time-stamped logger objects and multi-stream output variants are
-commonly used within Mailman scripts that run disconnected from a
-terminal, to capture errors.
-
-Loggers are applied in Mailman Web-associated components with another
-useful refinement.  All Web CGI scripts are launched via a driver
-script.  The driver script launches the intended, job-specific scripts
-within the context of an unqualified try-except statement.  If any
-exception escapes the job-specific script - including ones that simply
-cannot be caught within a script, for instance syntax errors - then
-the driver catches the exception and handles them in a useful way.
-The driver produces the traceback and a listing of all the HTTP
-environment variable settings both to stdout (HTML formatted, for
-rendition on the Web), and to the error log file.  This way, the Web
-visitor is provided with informative feedback, including
-e.g. instructions about contacting the site administrator, if they are
-inclined, and also the site has a detailed record of the error.  (See
-[Figure, "Excerpt from CGI Driver Script Code"], showing the use of
-error loggers and the comprehensive exception guard.)
-
-The CGI driver script, itself, is small and carefully hardened, in
-order to minimize the chance that it will introduce errors where they
-won't be caught.  The same driver is used for all the the underlying
-CGI scripts, increasing the complexity of the driver a bit, but
-ultimately reducing the overall complexity, and increasing the
-exercise, and ultimately the hardening, of the driver script overall.
-
-[Figure: Excerpt from CGI Driver Script Code.
-
-    <code>
-	try:
-	    logger = StampedLogger('error',
-				   label='admin',
-				   manual_reprime=1,
-				   nofail=0)
-	    multi = MultiLogger(sys.__stdout__, logger)
-	    scriptname = sys.argv[1]
-	    pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname])
-	    module = getattr(pkg, scriptname)
-	    main = getattr(module, 'main')
-	    try:
-		main()
-	    except SystemExit:
-		# this is a valid way for the function to exit
-		pass
-	except:
-	    print_traceback(logger, multi)
-	    print_environment(logger)
-    </code>
-]
-
-Structural integration of error logging within the Mailman framework
-eliminates the need for every CGI or mail handling script to do
-explicitly take care of logging, and it increases the detection and
-pinpointing of faults early in the development cycle.  This
-incorporation depends on Python's high-level exception mechanism,
-polymorphism, and a standard file-object protocols for a thorough,
-no-hassle implementation.
-
-			    Web Interface
-
-Mailman provides an interface to MailList objects via CGI, extending
-programmatic access to the World Wide Web.  The MailList base class,
-HTMLFormatter, contains MailList-specific HTML widgets, built upon an
-HTML widget library which is also part of Mailman.  The underlying
-library provides a full range of modest HTML document presentation and
-CGI form widgets, as well as cookie handling for authorization.
-Together with complete access to Mailman mailing lists via the MailList
-object, this general mechanism enables publishing access to any aspect
-of MailList operation to the Web.
-
-On this we build typical Web-related functionality, such as an
-overview of the mailing lists on the site, and review and subscription
-to particular lists, available via the Web.  (See [Figure: "Mailing
-List Home Page"].)  In addition, we also extend administrative
-customization of MailList operation (see the Configuration Options
-section, below), administrative action on the disposition of
-subscriptions and postings being held for approval, and subscriber
-control of their subscription status, customization options, and
-password, among other things.
-
-The elaborateness inherent in applications that programmatically
-generate Web documents, and the typical lack of a local operator and
-error console, can complicate development and debugging of them.  The
-use of Mailman's logging utilities, as described above, provides
-reporting of unexpected errors, and also provides convenient means for
-debugging flag "printouts" when exercising Mailman's Web interfaces
-via the Web.
-
-[Figure: "Mailing List Home Page".
-
- [user-ui.jpg]
-
-]
-
-Configuration Options Mechanism Exploits Namespace Dynamicism
-
-One significant subsystem demonstrating the power of the interface
-between MailList objects and the Web is the mailing list
-customization-options mechanism.  (See [Figure: "Admin Options
-page"].)
-
-MailList configuration options are expressed as simple data structures
-(tuples) specifying the name of the MailList's data member which
-contains the underlying setting, the type and layout of the HTML user
-interface element for the option, a brief description, and an optional
-elaborate description.  These options are collected into lists
-according to rough categories, e.g. list-privacy specific options, or
-digest specific settings.  (The option lists also include string
-entries which are used to annotate their presentation, typically at
-least including a header describing the category of the set.)
-
-These option descriptors dictate the contents of Web pages by which
-the mailing list administrators customize the behaviors of their mailing lists
-- coupling the CGI widgets on the pages with the underlying settings
-in the MailList objects.  Python's dynamic namespaces and high-level
-data structures, among other things, enables this simple mechanism to
-couple user interface with the underlying data members.
-
-
-[Figure: "Admin Options Page".
-
- [admin-ui.jpg]
-
-]
-
-
-The elementary nature of the mechanism, in turn, simplifies the
-process of adding new configuration variables or changing existing
-ones - a common occurrence when new features are added or existing
-ones are changed.
-
-The early formal structuring of the options has provided another
-benefit - it enables central enhancement of the options mechanism as a
-whole.  One recent example is addition of a help mechanism, which
-entailed adding the optional slot for elaborate descriptions and a
-corresponding addition to the presentation mechanism to offer help for
-those variables that contain the elaborate description.
-
-These option description tables could and should be divided into
-plugin directories, to further separate the introduction of new
-options from the main body of the program, enabling two benefits:
-
- - Isolation of the program from disruption due to faults in the
-   option descriptions (which tend to be changed more commonly than
-   other parts of the program).
-
- - Reevaluation of the option descriptions while the program is
-   running (which will be particularly useful when the program is able 
-   to run as a persistent daemon)
-
-Languages lacking the ability to directly access and effect runtime
-namespaces could not do any of this without significant and cumbersome
-indirection, hence obtuseness of the necessary code.
-
-		Drawbacks, Lessons and Open Questions
-		=====================================
-
-We discussed a small sample of some key Mailman features exhibiting
-the versatility of the design and implementation.  Below we discuss
-some inherent drawbacks, and also some lessons learned and open
-questions we're still pondering.
-
-The MailList object use of mixins has the drawback that it gathers all
-method and data member names in the same namespace.  The requires
-defensive programming to avoid collisions.  In practice it is hardly a
-problem, except...
-
-The Mailman configuration options compound this danger by directly
-populating the list object with numerous data members representing the
-options values.  We should reduce this load by encapsulating the
-options within a class object tailored to getting and setting the
-options as attributes.  This would also afford additional
-functionality on options, such as better defaulting relationships.  In
-this approach, maillists that do not customize an option would track
-changes to the central setting, while currently the maillists lock in
-make separate copies of the settings when they are created.
-
-Early versions of Mailman used broad, unqualified except clauses,
-masking unintended exceptions and making it extremely difficult to
-track down the origin of faults contained therein.  In practice,
-unqualified except clauses should never be used unless the intention
-is to catch and actually handle any contained failures.  (Code that
-does general failure handling can be seen as an executive of the code
-being handled.  For instance, the single CGI driver script, which
-directs the traceback and debugging info to the appropriate
-destinations, plays this role w.r.t. the CGI scripts.)  In general,
-except clauses should be as completely qualified as possible, and
-should be moved as close to the exception they're meant to catch as
-can be handled.
-
-One fundamental question concerns the pitfalls of dynamic typing in a
-large system.  In statically typed systems, the requirement for
-explicit variable declaration exposes most typos and many types of
-interface misuse at compile time.  Python's handling of dynamic types
-exposes such errors only at runtime, and only when the faulty code is
-executed.  This can mean that errors in obscure branches can stay
-hidden for a long time - and pop up when least expected.  As systems
-get larger it becomes harder to exercise all the code paths,
-increasing the difficulty of exposing such errors.  At what point do
-the benefits of static typing outweigh the versatility of dynamic
-typing?  Are the respective benefits even directly comparable?
-
-			      Conclusion
-			      ==========
-
-The desirability of continuing evolution in an MLM suggests a model of
-the system as being perpetually unfinished - with at least some parts
-at any one time being continuously developing prototypes.  Prototyping
-and rapid development are among Python's clear strengths, and
-invaluable in this regard.
-
-Mailman exploits many of Python's features, including native object
-orientation, multiple inheritance, polymorphism, high-level control
-structures like exceptions, conventional protocols, dynamic access to
-namespaces, cogent data structures, and a wealth of standard
-libraries.  The power of the language, combined with it's tendency to
-readability, enables development of sophisticated systems with
-approachable, untortured code.  This has already paid off, both in
-easy integration of valuable new subsystems, and in accumulation of
-contributed code from the user community, even this early in Mailman's
-development.
-
-======================================================================
-References
-
-AMK "Pipermail", Andrew Kuchling
-http://starship.skyport.net/crew/amk/maintained/pipermail.html
-
-DC "Document Template", Digital Creations, L.C.
-http://www.digicool.com/releases/bobo/DocumentTemplate-rn.html
-
-ESR "The Cathedral and The Bazaar", Eric Raymond
-http://sagan.earthspace.net/esr/writings/cathedral-bazaar/cathedral-bazaar.html
-
-JV "Mailman: The GNU Mailing List Manager", John Viega, Barry Warsaw,
-Ken Manheimer,
-Accepted paper for LISA '98, Dec. 6-11, 1998 Boston, Massachusetts 
-
-LO "Mailman", www.list.org
-http://www.list.org/
-
-MD "Mailman-developers", mailman-developers@python.org
-
-RF "HTMLgen", Robin Friedrich
-http://www.python.org/sigs/web-sig/HTMLgen/html/main.html
diff --git a/doc/IPC7/ipc7.doc b/doc/IPC7/ipc7.doc
deleted file mode 100755
index 4034be032..000000000
--- a/doc/IPC7/ipc7.doc
+++ /dev/null
diff --git a/doc/IPC7/ipc7.doc.gz b/doc/IPC7/ipc7.doc.gz
new file mode 100755
index 000000000..e13bb4aac
--- /dev/null
+++ b/doc/IPC7/ipc7.doc.gz
diff --git a/doc/IPC7/ipc7.ppt.gz b/doc/IPC7/ipc7.ppt.gz
new file mode 100755
index 000000000..7fe2cd14b
--- /dev/null
+++ b/doc/IPC7/ipc7.ppt.gz