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

[Alexander Klenin]

On Fri, Jun 18, 2010 at 20:15, Graeme Geldenhuys
<graemeg.lists at gmail.com> wrote:

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

In my view, the points for XML vs INI are:
1) well-defined encoding support
2) well-defined quoting
3) ability to represent arbitrary hierarchy in a consistent manner
(vs. different methods for different ini-files)
The points against XML are:
1) unsuited for processing by humans
2) inefficient storage due to closing tags -- not important because
config files are rather small
3) somewhat inefficient in processing -- which can be ameliorated by a
good XML library,
  I do not actually know how good FPC/Lazarus libraries are.
4) reading/writing code is ugly and full of duplication -- but this is
a problem of Lazaurs,
  not intrinsic to XML itself

>From these points, it seems to me that benefits of XML out-weight it's
deficiencies.

However, if we would discuss a format that Lazarus should use
(which we do not, according to the original post ;-),
I would like to suggest a better alternative to both: lfm files.
Benefits of LFM vs. XML:
1) compact
2) human-readable
3) can be read/written directly to the object via RTTI, thus
drastically simplifying read/write code
(I estimate a few thousands lines of code might be eliminated from Lazarus).

Benefits of LFM vs. ini:
1) has now-quite-well-defined, but good enough support for encoding and quoting
2) is able to represent arbitrary data structures as well as XML

See below for an example.

> 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.
> 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?
>
> -------------------[  compileroptions.ini
> ]-------------------------------------
> [SearchPaths]
> IncludeFiles=$(ProjOutDir)/
> UnitOutputDirectory=units/$(TargetCPU)-$(TargetOS)/
>
> [Parsing]
> UseAnsiStrings=1
>
> [Other]
> UseMsgFile=1
> CompilerPath=$(CompPath)
> ---------------------------------------------
>

object Options: TLazCompilerOptions
  object SearchPaths: TSearchPaths
    IncludeFiles='$(ProjOutDir)/'
    UnitOutputDirectory='units/$(TargetCPU)-$(TargetOS)/'
  end
  object Parsing: TParsingOptions
    UseAnsiStrings=1
  end
  object Other: TOtherOptions
    UseMsgFile=1
    CompilerPath='$(CompPath)'
  end
end


-- 
Alexander S. Klenin