On 2000.06.30, in <14684.61773.275647.868844@anthem.concentric.net>, "Barry A. Warsaw" <bwarsaw@beopen.com> wrote:
I'm not exactly sure why you want such conversion tools. It's very
Hypothetical example: when people fill out the form to request a mailing list, they check off boxes for the initial configuration of the list, and we generate the list in that configuration.
Or: it's the end of an academic year, and we've just closed 6,000 accounts. We want to either rewrite subscriptions with people's new alumni addresses, or remove them from the list. (The latter's not a big problem, I know.)
Or: again, it's the end of a year, and we've just closed 40 accounts which own mailing lists. We need to lock the lists pending resolution of new ownership, because our EAUP prohibits services which don't have accounts-eligible sponsors.
Is that convincing?
easy to write a little Python script to hack on or inspect config.db (see bin/dumpdb),
Yes, but it's easier if I don't need to learn Python first (and do it in a language that I'm going to use for other, related tasks). None of my administrative tools written in C, Perl or shell require integration with (correspondingly) C, Perl, or shell. Why should my Python software require irt with Python?
Suffice to say that /eventually/ config.db will go away because all this information will live in a real database.
That's good, too, if the database isn't required to be SQL or something. I think JC said that it was to be pretty open, though.
-- -D. dgc@uchicago.edu NSIT University of Chicago