[Mailman-Developers] Re: Config.db
Barry A. Warsaw
Fri, 30 Jun 2000 15:49:16 -0400 (EDT)
>>>>> "DC" == David Champion <email@example.com> 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
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
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,
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.