Graeme Geldenhuys wrote:
BTW: Does anybody know what INI actually stands for? Initialization maybe?
It's as much of "initialization" as MS could fit into a three-letter extension when it started using it for Windows in the early-80s.
Now both examples contain the same information, but lets be honest.. Which one is easier to read (via human or program), manually tweak if needed via human in IDE screws up, takes up less disk space. I fully understand that XML has it's place in data transport and helps describe complex data. But using XML for something as simple as storing a few application settings. It just seems very inappropriate in this case, and a classic example of over-engineering.
I agree, but quite frankly we've got it, it works, so let's live with it. Unless, of course, you're volunteering to write a unit which will convert seamlessly and reliably between the two formats, so that the IDE will work out whether the user has updated the human-readable one and import accordingly.
Frankly, .ini files that users could (and did) update manually with the wrong kind of editor were a support nightmare. But (as others have said) that doesn't detract from their usefulness.
I'm currently using a TInifile subclassed to add array- and record-style setting names, which pass nicely through the standard reader. However that raises a significant question: if I'd coded something to expect a simple value and then needed to turn it into an array, how many .ini files would need to be updated and could a program do it 100% reliably?
That isn't quite academic: it has, in effect, happened now that the IDE handles multiple editor windows. XML- and any worthwhile parser- knows how to handle that out of the box, a non-standard hack might not.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
