I have to disagree with this. XML, when done properly, can be good both for people and for machines. I've seen it done this way, and worked with this kind of configuration for quite a while. It can be done well, and it can be done badly.
When done well, a few simple conventions can make the XML file just as handy as a flat text file - often even better since complex configurations can be represented more clearly. That done, a GUI can then be more easily developed which will read the XML configuration file, modify it, and save the results without making it difficult to open again in a plain old text editor. This is a much harder trick to do reliably when a flat file is employed. I think with the right level of effort you will find that an XML file can be developed that will not make you want to run for the hills and will quite possibly feel even better than a plain old text file. My $0.02 _M PS: One of the really nice things about an XML file like this is that folks will be able to easily cut and paste meaningful sections of the file to share with others on the list - and to show as examples. On Monday, July 12, 2004, 3:46:24 PM, decjunkmail wrote: d> Hi, d> I vote NO for XML. d> I'm sorry, but XML is much more like a registry setting or a d> binary configuration file -- Great for programmatic manipulation, d> but terrible for manual/interactive use. d> A text file in notepad is easy to change and edit interactively d> (even remotely on low-bandwidth connections) - as long as the goal d> for declude configuration files is to facilitate quick and easy d> changes, then it should stay as a text file. d> If the goal is to create a parametric-driven, API for automatic d> configuration/provisioning or programming, then XML or registry d> keys, or a binary database is fine. d> Note - I have used some XML, mostly with ASP.NET/VB.NET and d> although I can dig my way around config.net files and the like, I d> still prefer ".ini" files if I'm going to be fiddling with d> configurations. d> Yes, XML is great to serialize database structures, move them d> across web services, or dissimiliar internal database stores, but d> they are not as friendly for configuration files. d> -----Original Message----- d> From: [EMAIL PROTECTED] d> [mailto:[EMAIL PROTECTED] On Behalf Of David d> Sullivan d> Sent: Monday, July 12, 2004 9:43 AM d> To: [EMAIL PROTECTED] d> Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat d> Lookup Database test for Declude JunkMail d> Ok, couldn't resist my $.02 M>> sense, but I think they are putting the cart before the horse. Wouldn't M>> it be much better to work on creating a new format for the config files d> <DREAMING> d> Like an XML based config file that incorporated Junkmail, Virus and d> Hijack configurations as well as per user controls. Ooooh, how much d> easier that would be to control from code.... d> </DREAMING> M>> In the mean time, it would make sense to also spend some time tightening M>> up loose ends which have not been getting that much attention. If you M>> asked for everyone's top 5 list from around here at least, I'm pretty M>> sure that it would include things besides a new DNSBL test on virus data M>> with a GUI installer, or the GUI itself. Declude is very capable at the M>> moment, but there are some loose ends that could be tied up over a short M>> period of time that would really help finish the foundation. Voicing d> Like a sender white list option for Vulnerabilities in DV. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
