diff options
| -rwxr-xr-x | doc/IPC7/IPC7.ppt | bin | 227327 -> 0 bytes | |||
| -rw-r--r-- | doc/IPC7/README | 8 | ||||
| -rw-r--r-- | doc/IPC7/arch.txt | 178 | ||||
| -rw-r--r-- | doc/IPC7/draft | 552 | ||||
| -rwxr-xr-x | doc/IPC7/ipc7.doc | bin | 152573 -> 0 bytes | |||
| -rwxr-xr-x | doc/IPC7/ipc7.doc.gz | bin | 0 -> 87676 bytes | |||
| -rwxr-xr-x | doc/IPC7/ipc7.ppt.gz | bin | 0 -> 147911 bytes |
7 files changed, 8 insertions, 730 deletions
diff --git a/doc/IPC7/IPC7.ppt b/doc/IPC7/IPC7.ppt Binary files differdeleted 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 Binary files differdeleted 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 Binary files differnew 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 Binary files differnew file mode 100755 index 000000000..7fe2cd14b --- /dev/null +++ b/doc/IPC7/ipc7.ppt.gz |