[Mailman-Developers] Re: Config.db

[Barry A. Warsaw]

>>>>> "DC" == David Champion <dgc@uchicago.edu> writes:

    DC> Hypothetical example: when people fill out the form to request
    DC> a mailing list, they check off boxes for the initial
    DC> configuration of the list, and we generate the list in that
    DC> configuration.

This can be done with bin/config_list.

    DC> Or: it's the end of an academic year, and we've just closed
    DC> 6,000 accounts.  We want to either rewrite subscriptions with
    DC> people's new alumni addresses, or remove them from the list.
    DC> (The latter's not a big problem, I know.)

bin/clone_member or bin/remove_member

    DC> Or: again, it's the end of a year, and we've just closed 40
    DC> accounts which own mailing lists.  We need to lock the lists
    DC> pending resolution of new ownership, because our EAUP
    DC> prohibits services which don't have accounts-eligible
    DC> sponsors.

Hmm, that's harder and I think being able to write to config.db would
even help you there.  What's involved in `locking a list'?  Do you
mean that email to the address should bounce, should autorespond but
not forward the email, hold the mail in a quarantine for later
delivery if the list is enabled?

    DC> Is that convincing?

Somewhat.  I totally agree that you'll want to be able to have script
and command-line access to list configurations, but I believe the
tools already exist to do this without having to touch config.db
directly.  I'd maintain largely the same attitute if there was a real
db on the back-end.

    >> easy to write a little Python script to hack on or inspect
    >> config.db (see bin/dumpdb),

    DC> Yes, but it's easier if I don't need to learn Python first
    DC> (and do it in a language that I'm going to use for other,
    DC> related tasks).  None of my administrative tools written in C,
    DC> Perl or shell require integration with (correspondingly) C,
    DC> Perl, or shell.  Why should my Python software require irt
    DC> with Python?

Well, I won't answer that learning Python takes about half a day for
anybody with C or Perl experience <wink>.

    >> Suffice to say that /eventually/ config.db will go away because
    >> all this information will live in a real database.

    DC> That's good, too, if the database isn't required to be SQL or
    DC> something.  I think JC said that it was to be pretty open,
    DC> though.

My very vague thoughts at the moment are that there will be a db API
with pluggable back-ends.  We'll ship with a connection to a GPL
compatible database (e.g. PostgreSQL, MySQL, ZODB) but you'd be able
to swap out the back-end if you want.

-Barry