Hi,
I'm sorry for my bad english...
I'd like to read the file config.db with a perl-program, where I can read informations about the file format?
Thank's to all.
Ciao Davide
Davide Rizzo agemo@agemo.cc
"agemo" == <agemo@agemo.cc> writes:
agemo> I'd like to read the file config.db with a perl-program,
agemo> where I can read informations about the file format?The config.db is a marshal[1] of a Python dictionary object. The marshal format, however, is undocumented on purpose. The contents of the dictionary are all the attribute/value pairs of the MailList instance. See MailList.Save() and MailList.Load() for details.
-Barry
[1] http://www.python.org/doc/current/lib/module-marshal.html
"Barry A. Warsaw" wrote:
"agemo" == <agemo@agemo.cc> writes:
agemo> I'd like to read the file config.db with a perl-program, agemo> where I can read informations about the file format?The config.db is a marshal[1] of a Python dictionary object. The marshal format, however, is undocumented on purpose. The contents of the dictionary are all the attribute/value pairs of the MailList instance. See MailList.Save() and MailList.Load() for details.
-Barry
[1] http://www.python.org/doc/current/lib/module-marshal.html
Perhaps a portable method would be something like "dumpdb", perhaps modified slightly to be a little more parsing-friendly? (if readonly access is all that's required..)
On 2000.06.30, in <395CE58E.D4512B7B@west.sun.com>, "Dan Mick" <Dan.Mick@west.sun.com> wrote:
Perhaps a portable method would be something like "dumpdb", perhaps modified slightly to be a little more parsing-friendly? (if readonly access is all that's required..)
I would appreciate being able to load an edited dump, too. To me, this nonportability -- and thus the mere fact of using the Marshal module -- is very disturbing. That's considerably mitigated if there are tools for conversion in both directions, though.
-- -D. dgc@uchicago.edu NSIT University of Chicago
"DC" == David Champion <dgc@uchicago.edu> writes:
DC> I would appreciate being able to load an edited dump, too. To
DC> me, this nonportability -- and thus the mere fact of using the
DC> Marshal module -- is very disturbing. That's considerably
DC> mitigated if there are tools for conversion in both
DC> directions, though.I'm not exactly sure why you want such conversion tools. It's very easy to write a little Python script to hack on or inspect config.db (see bin/dumpdb), but I'm not even sure why you'd want to do that either.
Suffice to say that /eventually/ config.db will go away because all this information will live in a real database.
-Barry
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
"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
participants (4)
-
agemo＠agemo.cc -
bwarsaw＠beopen.com -
Dan Mick -
David Champion