Would it be interesting/cool//neat/necessary/(or whatever) to have XML wrappers in FF?! I for one have not been using XML (yet), but with a low treshold for using/learning it, I guess it would be a very use-/helpful feature to have. I guess XML will put INI-files totally in the shadow some day, if it hasn't already?
That is a fantastic idea Haakon.
Paul has the XML stuff from Don already down to a science and Don is using FF as well so it would be little effort (I hope) to get something up and running.
Especially since M$ has in the documentation that the ini functions are for "compatibility with 16 bit Windows"...AKA bye-bye ini files.
Microsoft were saying that about INI files 10 years ago if I remember correctly. They had this bright idea with Windows 95 that the registry was the "in thing" and you didn't need an INI file.
Don't write off the dear old INI file. I find them incredibly useful, and what's the point of replacing something simple with something complex if it simple approach does the job?
Andrew
While XML is a capable, self describing container, and as much as I have resisted jumping on the whole "It's bloated, it's bloated" band wagon, it is an obese container for many applications. Regardless, FF wrappers would be a really good thing.
Notwithstanding, INI files have no equivalent afaic, and I don't they're going away too soon. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/unicode_layer_ini_file_functions.asp)
I agree with FF supporting XML via wrappers. I wrote a couple of functions for doing this job some time ago - XmlPack() and XmlUnpack().
But I also agree with the bloat issue. If the idea is to save simple state data then I really cannot see the benefit of adding lots of fancy markup, if an INI file does the job!
There's certainly a place for XML, but I remain unconvinced that as a dumping ground for simple state data it's necessarily a good choice.
Andrew
m$ has reversed its opinion of using the registry for all app config data a while back and told us to go back to .ini files. since i never left them in the first place, all of my code was still up to their standards:D
per xml, i use it when the data needs to be stored in a heirarchal manner. if its flat, then an .ini file is fine. traversing the xml tree is a fast process (once everything is parsed) and makes the otherwise complicated data quick to decipher. space is a problem as it is horribly verbose. if the data needs to change frequently you're better off with a database, though. updating .ini and xml files is horribly inefficient as the whole file needs to be re-written.
i think paul's choice of storing in xml is a terrific idea! it makes it easy to integrate with firefly and deciphering is a piece of cake.
--don
I worked on a web project about 5 years ago and used an INI file on the web server as a simple database for populating comboboxes. Its performance was pretty good.
The other issue about having to rewrite the whole file is valid, however on an NT system that write can be delayed for a longish period of time on a busy system. INI files are cached automatically I believe.
Andrew
Well.. - then we need INI-wrappers as well. :mrgreen:
I've abused the INI-concept before, and as I never actually bothered to see what the XML fuzz was all about, INI-files normally would go a long way for me..