quote:Original post by Digitalfiend
You do realise that the Registry is just a binary file right? It doesn''t have any magical ability to enforce the rules you are talking about. The Registry API, the functions you use to access/manipulate the Registry, does. So basically:

Registry File is accessed using the Registry API
XML File is accessed using a XML Parser/API

I don''t see a lot of differences here - with regards to ensuring integrity. Both APIs enforce structure (layout and data type) and integrity.

Your argument is flawed in my opinion.

I think things are getting mixed up here :

Ok, the reg. if accessed via the API or reg edit tools inforce the data type being written to the reg. to the correct type.

XML files, again if accessed via teh API or a tool which enforces the type of data which is written.

HOWEVER the flaw with teh XML file is you CAN edit it with something like notepad which DOESNT inforce type checking. Now, I''m aware that the reg. could be edited with a HEX edit program however that does assume the user has (a) a hex editor and (b) can find the reg. files, where as am XML data file isnt overly hard to find

And just to add to the arguement, forget INI files, I''d go with a mix of the reg. for data which SHOULD be lost when windows is reinstalled and either custom data file or maybe a gzip compressed XML file (compressed to stop the user fiddling with it without the correct tools). As for location, there is a reason you have a my documents folder

Finaly, on the subject of ''huge reg. causing a slow boot'' my reg. size is currently 29meg, and Win2K restricts the size (54meg is its max), now, imho, thats not really a huge size and @ DMA66 loading speed it wont take very long to load that info memory.

also ... XML is fragile, only in the sense that any hand edited data is fragile, and any corruptable file is fragile. With a registry setting OR xml file, the security of the data is only as good as the program''s ability to deal with it ...

if the user types 100 into a registry entry which expects an integer between 1 and 10 - perhaps for weapon selection hot-key or something ... the registry is likely MORE fragile than xml .. because with proper xml scheme you can guarantee that all configuration data is within a designated range ... and here''s the real kicker ... your user''s can use their prefered xml editing and validatation tools when they want to perform mods ... so when they change a 5 to a 6, they can hit "validate" and get a "value out of range" message from their editor. So .. where''s your cool registry stuff then?

and as for binary data ... we''re talking about a CONFIGURATION file ... why would you have binary configuration data? ESPECIALLY if the user is meant to edit it. don''t you think that would fall more under the category of binary resources (which of course may be user replaceable if you wish).

also ... xml allows for specified encodiings, and automatic transcoding ... therefore you can port your windows game to Mac, and Linux, and sell it in India, all the while leaving the simple character storage (ASCII, UTF-8, UTF-32, etc) translation up to the XML parser.

as for parsing cost .. xml is quite expensive ... especially with validation ... but that also means that you can output a meaningful message for bad configuration files, WITHOUT writting the validation code by hand.

as for internal (post-parsing) storage and access. there is no reason why xml wound not be as efficient as any possible heirarchal data storage means. at work we use a SAX parser which fills in a simple tree of XMLElement and XMLAttribute objects ... with the same efficiency specs as or previous vesion which used IniGroup and IniSetting classes ...

and, as far as by hand .. man it''s great to sit down and in 10 minutes create a prototype of an xml data file format (such as I did last night for my sci-fi game''s race file), then write the code which creates a game class from the parsed data (ImportRace(XMLElement *), XMLElement* ExportRace()), and then go back and add a simply schema which reflects EXACLTY the ability of your loading code to handle ... all in 2.5 hours ... from started to tested.