RE: [GD-General] (Really) XML for portable preferences library

[Nicolas R. <nic...@fr...>]

Hi,

Just re-read the entire thread, but its getting too long (at least for
me) and couldn't find any suitable answer to XML pros and cons.
As already stated, XML is just a way of storing things. Just like some
kind of "dynamically extensible binary format" in the text form. There
is one word here which is (in my sense) the most important one (at least
for preferences ! :) ): EXTENSIBLE.

It means that you can add/substract any kind of data/command/tag without
having to rewrite entirely everything. Let's take an example:
You have the following memory data:

Struct C {
	...Some data ...
};

Struct B {
	...Some more data...
	C m_c;
};

Struct A {
	...Still data...
	B m_b;
	C m_c;
};



Now you want to read/write several A entries from a persistant location:
- simple "raw" file:
  pros: fastest possible.
  cons: breaks as soon as the C or B structure has changed (having to
"patch" all files contains some A data as well, but how one would know ?
=> you need some kind of "big-data-boss" knowing what needs to be
"re-saved").

- version tagged file:
you write some kind of "version" value for each structure, each
structure has its own loading/saving functions (usually virtual generic
load/save in C++). Loading depends on version read, saving always saving
latest version.
  Pros: fast. Backward compatibility. 
  Cons: Becomes a real mess when you have 6/7 versions around to
support. No backward compatibility (file v2.1 cant be read by v2.0).

- property tagged file:
You write each data entry with its own "tag" (basically a "property
name", a "property type" and its value). Unknown tags are discarded.
  Pros: Almost same speed as the version tagged file. Full
backward/upward compatibility.
  Cons: nx times slower than the "raw" reading.


Here comes the XML: XML provides a completely "normalized" way of doing
solution 3 in a portable, easily editable way (nice for debugging).
We have completely dropped solution 2.
Solution 1 is kept for large binary intrasic formats (textures,
mesh-data, ...). 


For preferences this is a good choice since it must be fully upward
compatible (I simply hate those programs that reinitialize preferences
at update), fully backward compatible (I can send my preferences to a
friend who is not having the exact same version), and editable by anyone
(don't you just hate when you select a crashing config, reloaded each
time you launch the game, making impossible to change it back, without
reinstalling the game... Saw one such game earlier this month !).
Preferences don't need to be that fast (for us, it appears that time
spent in CreateFile is bigger than in any other parts of the code during
preference loading).

We did prefer another choice of script-form preferences (mainly for code
reusage reasons) ... But hey, doing:
Rendering-prefs {
	api = OpenGL;
	width = 1600;
	height = 1200;
}
Or
<RENDERING>
   <PROP name="api">OpenGL</PROP>
   <PROP name="width">1600</PROP>
   <PROP name="height">1200</PROP>
</RENDERING>
Is quite the same anyway ! :)



Nicolas.