> Then I got thinking of in that case, there'd be a 'meta-config', and > three other individual configs. This got me thinking about a yum.conf > that looks like this (please to forgive simulated XML): advantages to xml for the config files - it can easily be handled by a program to add/subtract entries, etc. That's cool. disadvantage - you need to write a program to manipulate them b/c, while they CAN be handled by humans it is typically a pain in the ass to do so. I tend to use xml as a data-interchange format less than a user-interactive format. so the header.info file format may, at some point, move to a headerinfo.xml b/c no one should ever really have to interact with those directly. > This would get rid of the nice & clean existing syntax though. I don't > know how many people would need/utilize this. but, the 'template' could > the problem is - I'd much rather have a single mechanism for the config. so it is EITHER configParser OR xml for the config file, not both. I mention this only b/c maintaining both of them would suuuuuuuuuuck. I'm not, necessarily, opposed to xml for the script/template format. > then have the following format, or some such: > > <template> > <group name="redhat"> > <action type="groupinstall">tom</action> > <action type="remove">harry</action> > <action type="install">ted</action> > <action type="update">*</action> > </group> > <group name="freshrpms"> > <action type="install">do</action> > <action type="update">*</action> > </group> > </template> > > obfuscated... but just a thought. I don't have a problem with the template being xml. What would be the motive? So you could have an interface to design them? We're not talking about a terribly complex language. having said that - things tend to grow - might be better to plan ahead. then again - would it really help much? I'm not sure where I come down on this. other comments from the peanut-gallery? :) -sv
