Since these papers have been published, we might as well release them

now.  By gzip'ing them we can get them down to reasonable sizes.

Check in the compressed versions, remove the uncompressed versions,
add a README, and remove the old intermediate files.

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