>>>>> "BR" == Brock Rozen <brozen@webdreams.com> writes:
BR> Another idea is to have this same file -- while maintaining the current
BR> config files.
I'm way ahead of you.
BR> Thus, when a lists command came around, the config file would have
BR> already been parsed.
The new config file _is_ a "preparsed" file; Data::Dumper writes it out in
a format directly readable by perl. For Perl5.005 I'll probably be able to
write out Perl bytecode directly. (But by then we'll probably just be able
to compile all of Majordomo to C anyway. Right now the compiler handles my
code much better than it ever handled 1.x, but it still has a ways to go.)
The old config file is still there; I can read and write it (and can do it
a good bit faster than the 1.x code does since I don't use formats or that
clunky old data structure). It is only there as a nod to backwards
compatibility, though.
BR> Hmmm...getting around the local edit problem would be to have a CRC
BR> check of a sort.
No way. I added all of this to lower the overhead; there's no point in
raising it back up again. The way things are shaping up, you can chmod 600
everything (except the directories; 700 for them) and let no human in
except for installation or to change the config defaults file. (You can
put the code in a different place from all of your lists.) If you edit
stuff, it's your problem. Majordomo itself never sees this file and has no
control over it's in it; it asks Perl to dump part of its internal data
representation to a file.
I'm hoping to do a public code snapshot once I finish what is currently my
third rewrite of all of it.
- J<
Follow-Ups:
References:
|
|
