-
-
-| |
-
-
-
-Developer Resources
-
-If you're the kind of person who loves to get elbow deep in code,
-there are lots of opportunities to dig into Mailman. You may want to
-find a project on our Mailman
-TODO list or on the
-Mailman
-design notes wiki. Because Wikis are intended to be
-collaborative, you're free to contribute to this page in true Wiki
-fashion. You will also definitely want to subscribe
-to the mailman-developers mailing list.
-
-SourceForge Project Page
-
-Developers should start with the
-Mailman project at
-SourceForge. All patches and bugs should be submitted here so
-they won't get lost, although it is also requested that you inform the
-mailman-developers list about your submissions.
-
-IRC
-
-Some of the Mailman developers also occasionally hang out on the
-mailman IRC channel at freenode.net, though attendance
-has been spotty lately.
-
-
-
-Future plans
-
-Now that Mailman 2.1 has been released, I want to start thinking about
-what will be in Mailman
-3.0. I intend to use the wiki for most design artifacts, and the
-mailman-developers mailing list for most discussions. The items that
-are high on my list (which is by no means complete or definitive)
-include:
-
-
-- Consolidated user database -- A user should have just one
-account for every mailing list they are members of at a site, and they
-should be able to manage all their options through this account.
-It should be possible to integrate these databases with a site's
-existing user management system to reduce duplication of data and
-effort.
-
-
- Unified template system -- Mailman has a somewhat fractured
-and inconvenient templating system, using both a homegrown HTML object
-model in Python and coarse templates filled in with data at rendering
-time. It can be near impossible to change the look and feel of the
-administration pages, and a small change to the u/i of other pages
-requires updates in all supported languages. I want to use a
-templating system like
-ZPT or
-Quixote.
-Actually, I plan to generalize the web interface so that many different
-templating systems could be used, although we'll pick one to ship by
-default.
-
-
- A Real Database -- Mailman uses an inefficient persistency
-system based on Python pickles, and every mailing list has its own
-pickled state. This has several disadvantages, including poor
-scalability, difficulty in doing cross-mailing list operations, and
-the virtual host limitation on list names. Mailman 3.0 will use a
-real database, perhaps based on
-ZODB or
-BerkeleyDB. Again, the goal is
-to generalize the interface to the backend database so that others can
-be used, but choose one and ship it by default.
-
-
- Component Architecture -- Zope3's
-component architecture provides some very nice organizational
-tools and software development methodologies. We'll be adopting many
-of these for Mailman 3.0, which will allow us to do the kinds of
-templating and database generalization described above.
-
-
-Stephan Richter has let an effort called
-ZMailman for integrating Zope and Mailman. I consider this a
-proof of concept of some of the ideas outlined above.
-
- |
-
-
