[Lazarus] Why was XML format chosen for storing settings in Lazarus IDE?

Mattias Gaertner nc-gaertnma at netcologne.de
Fri Jun 18 14:22:35 CEST 2010


On Fri, 18 Jun 2010 11:15:02 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> Hi,
> 
> I thought I would pose this question in a new thread seeing that the
> other thread got totally high-jacked (and not by me for a change). :)
> 
> I'm curious to know what was the reason behind the decision to use XML
> for storing simple Lazarus settings, instead of the much simpler INI
> format? This is a legit question and I'm very curious as to the
> answer. Please note, this is not a feature request or me telling the
> Lazarus devs to change yet another thing in Lazarus. This is simply me
> asking a question I don't have an answer too.

xml is only the backend.
No IDE config reads/writes xml directly, but uses components
like TXMLConfig or TConfigStorage to read/write Path/Value pairs. For
me it is important that the configs are independent of the backend and
could be changed for example to ini or a registry.
I think the hierarchical structure of the xml is more future proof
than ini (when more categories are added to a config).

 
> Here are some points that were raised before:
> 
> * FCL, LCL and Lazarus IDE have XML read/write code. They don't all
> work the same, and I doubt they all have the same functionality.

FCL and LCL have the same XML write/read code.
There is a UTF8 optimized version in the codetools directory, which is
also used by the IDE. Most configs can be read by both.


> * Not all code in Lazarus IDE uses the same XML read/write code

What do you mean?


> * Most XML examples in my ~/.lazarus/ directory would be much simpler
> presented if they where INI files.

True.
But they only need to be simple enough. So far no one had problems
reading the xml syntax.


> * FPC and Delphi has brilliant INI file support, and it's dead easy to use.

Same for xmlconfig.


> * What is the actual advantage of XML in this case or was it chosen
> simply because XML was the flavour of the month at time of
> implementation. Yes, at one point everything had to be XML or it just
> wasn't cool. :-)

No, then we would have accessed the DOM nodes directly.


> * Reading INI fast is FAST.

The ini file unit is much faster now than ten years ago. Same for the
xmlconfig. Reading the png of the splashscreen takes more time than
reading all IDE xml files, even if they contain thousands of units
and include files like mine.


 
> To make others understand my confusion regarding the XML choice, here
> is an example, using the compileroptions.xml file located in my
> ~/.lazarus/ directory.
> 
> -------------------[  compileroptions.xml
> ]-------------------------------------
> <?xml version="1.0"?>
> <CONFIG>
>   <CompilerOptionsVersion Value="8"/>
>   <CompilerOptionsSearchPaths>
>     <IncludeFiles Value="$(ProjOutDir)/"/>
>     <UnitOutputDirectory Value="units/$(TargetCPU)-$(TargetOS)/"/>
>   </CompilerOptionsSearchPaths>
>   <CompilerOptionsParsing>
>     <SyntaxOptions>
>       <UseAnsiStrings Value="True"/>
>     </SyntaxOptions>
>   </CompilerOptionsParsing>
>   <CompilerOptionsOther>
>     <CompilerMessages>
>       <UseMsgFile Value="True"/>
>     </CompilerMessages>
>     <CompilerPath Value="$(CompPath)"/>
>   </CompilerOptionsOther>
> </CONFIG>
> -----------------------------------------------------------------------------------------
> 
> This is a relatively small example, but still highlights my point.

The clever thing about the xmlconfig is that it only write changes
and auto deletes empty nodes. That's why you see such a flat xml file.


> Just looking at it gives me a headache. ;-) Now lets convert that to a
> INI styled file.
> 
> BTW: Does anybody know what INI actually stands for? Initialization maybe?

I guess yes.

> 
> -------------------[  compileroptions.ini
> ]-------------------------------------
> [SearchPaths]
> IncludeFiles=$(ProjOutDir)/
> UnitOutputDirectory=units/$(TargetCPU)-$(TargetOS)/
> 
> [Parsing]
> UseAnsiStrings=1
> 
> [Other]
> UseMsgFile=1
> CompilerPath=$(CompPath)
> ---------------------------------------------
>
> Now both examples contain the same information, but lets be honest..

.. that's not equivalent. You have combined sections and risks name
clashes.


> 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.

Of course you can hand craft nice ini sections if you know the full set
of options. But what if you don't know how a config will grow in ten
years?

 
> 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.

The xml backend of the IDE is only one place - the TXMLConfig. Change
that and the IDE would write ini files.


Mattias




More information about the Lazarus mailing list