I'm about to embark in a rather hairy problem and am in dire need of your enlightened views on it to prevent further suffering.

I'm using Config::IniFiles to create and manage the configuration files for both the client and server side of a distributed application.

I need to be able to read and modify my client side configurations remotely by sending text commands through tcp/ip sockets to listening ports in the remote machines from my server application in my local worst-station.

Of course, the ability to modify implies that I need some validation of what is being written to the config files, since it is what will be driving my (mostly) unsupervised app. And, if possible, of what is being read from the ini files.

Taking advantage of the grouping feature of the Config::IniFiles module, i'm trying to create a hierarchical tree that will follow a certain structure and in which only the final nodes have the most critical information.

And with the purpose of validating that what I write to the ini file as well as what I read from it have the structure I want, I'm creating a hash that outlines the...lets say "logic" structure that I want the ini file to have and a bunch of regexps to match stuff against.

Here's the (hopefully) self-explanatory validating hash:

my %IniStruct = (
        "^MONICA ROOT$" => {
                "^DEBUG$" => "^(YES|NO)$",
                "^BASEDIR$" => {
                        "REGEXP" => "^\/\w+[\/\w]*$",
                        "VALUE" => "-e FILENAME && -d _ && -r _"
                        },
                "^LOGFILE$" => {
                        "REGEXP" => "^\w+[\/\w]*$",
                        "VALUE" => "-e FILENAME && -f _ && -T _ && -r 
+_ && -w _",
                        },
                "^MONICASRVADDR$" => "^\d{1,3}\.\d{1,2}\.\d{1,2}\.\d{1
+,3}$",
                "^CONNECTIONTIMEOUT$" => "^\d{1,2}$"
                },
        "^MONICA CAT=\w+$" => {
                "^ENABLE$" => "^(YES|NO)$",
                "^DEBUG$" => "^(YES|NO)$",
                },
        "^CAT=\w+ SUBCAT=\w+$" => {
                "^ENABLE$" => "^(YES|NO)$",
                "^DEBUG$" => "^(YES|NO)$",
                },
        "^SUBCAT=\w+ (PARAM=[\/\w]+|GROUP=\w+)$" => {
                "^SCRIPT$" => {
                        "REGEXP" => "^\/\w+[\/\w]*$",
                        "VALUE" => "-e FILENAME && -s _ && -r _ && -x 
+_",
                        },
                "^ARGUMENTS$" => ".*",
                "^REGEXP$" => ".*"
                },
 );
[download]

And here's an example of the corresponding ini file:

[MONICA ROOT]
DEBUG=NO
BASEDIR=/export/home/monica/
LOGFILE=log/clntMonica.log
MONICASRVADDR=<<EOT
10.6.1.122:9000
EOT
CONNECTIONTIMEOUT=10

[MONICA CAT=OPSIST]
ENABLE=YES
DEBUG=NO

[MONICA CAT=INFORMIX]
ENABLE=YES
DEBUG=NO

[CAT=OPSIST SUBCAT=SECURITY]
ENABLE=YES
DEBUG=YES

[CAT=OPSIST SUBCAT=FSYSTEM1]
ENABLE=YES
DEBUG=NO

[SUBCAT=SECURITY PARAM=ZEROUID]
SCRIPT=bin/checkZeroUid.pl
ARGUMENTS= <<EOT
EOT
REGEXP=/^\d{1,3}$/

[SUBCAT=FSYSTEM1 PARAM=/]
SCRIPT=shells/fs.sh
ARGUMENTS= <<EOT
/
EOT
REGEXP=/^\d{1,3}$/

[SUBCAT=FSYSTEM1 PARAM=/VAR/RUN]
SCRIPT=shells/fs.sh
ARGUMENTS= <<EOT
/var/run
EOT
REGEXP=/^\d{1,3}$/

[CAT=INFORMIX SUBCAT=RATINGS]
ENABLE=YES
DEBUG=NO

[SUBCAT=RATINGS GROUP=DBSPACE]
SCRIPT=shells/informix.sh
ARGUMENTS= <<EOT
dbspace
EOT
EXPREG=/((^dbspace\s+allocated\s+free\s+pcused$)|(^\w+\s+\d+\s+\d+\s+\
+d{1,3}$)/
[download]

So basically, what I want to do (when reading) is to "walk" the ini file using the hash as a guide to validate both structure (by matching section headers and parameters within against the corresponding regexp in the hash) and content (by matching against a regexp AND replacing the string for the uppercase part in the VALUE nodes and then evaluating it).

When writing to the ini file, i'd again use the hash to validate what i'm about to write.

Of course, in both cases code would be needed to enforce the dependency of, say, a group on a subcategory, a category on the "monica" node...etc.

Now, my first thought was to use XML and a DTD (or even Schema?) for all this. For what i've read its the most logical way to go. But I had a number of problems installing the modules and their dependencies. After a number of days trying I was in a dead end with an expat library (or header, cant remember, drank a lot to forget).

Since these ini files (and their apps) will be installed in a number of machines (with various flavors/versions of unix and various versions of Perl), i thought that having problems to install XML in my machine could very well indicate possible problems when installing my code in other less updated hosts. And only a few of those would have internet connection, so just download what i need from the web is usually not an option.

Believe me, I DID give XML (or at least the modules I tried back then) installation a good try (I have my boss's whip marks on my back to prove it). Granted, I must have done something wrong, but at the time I couldnt spend more effort on it and had to let go.

So I guess a consolidated form of my question would be: would you consider that it is better to invest time and effort in the Config::IniFiles workaround? Or should I suck it up and learn how to create a local repository of all the stuff I need and a reliable method to automate the installation of a bundle that includes the XML modules and all their dependecies, learn to use schema and (conceivably) make my future life easy at the expense of a lot of exploration (waisted time, from my boss's point of view) and pressure at the present time?

Thanks for taking the time to read my question. Made it this long to explain where I'm coming from. Hope you can share your thoughts with me. Thanks in advance.