[Freeciv-Dev] Re: DataExchange: Persistent storage, File formats, Freeciv proprietary vs XML

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>]

On Wed, 30 Jun 2004, Ross Wetmore wrote:

> The strongest PRO I can think of for doing this is to leverage a
> lot of code development on XML to provide a single robust subsystem
> for a lot of the UI preferences and gamerules customization that is
> starting to make the multi-CIV flavour (as opposed to more-or-less
> single older CIV game played on the online servers. Phasing out a
> lot of slightly dissimilar subsystems and code in flavour of a more
> consistent set of practices and file formats will help push forward
> this effort.

We already use the .ini format for our UI preferences and gamerules. Look
at the tilespec or ruleset formats and "~/.civclientrc".

The question is do we wish to replace the .ini format with XML or not.

> But to the question is XML really necessary, the answer has to be
> not really.
>
> In fact the best way to cover all bets is to kickstart the process of
> splitting the file-format issues and persistent storage requirements
> into a two layer process by codifying an upper layer API that Freeciv
> uses to manage the persistence process, while blocking off the actual
> read/write parts of the code into an area that involves an
> implementation for arbitrary file formats. One can thus capture the
> current proprietary and XML solutions with a trivial substitution
> switch and when one gets to the point of using XML as the default is
> just a trivial update.

XML can capture everything the .ini format can achieve. It is in fact more
generic than the .ini format. For e.g. you cannot have nested sections in
.ini format.

> Previous postings on hardcoded/system/user preference defaulting
> provide a core block of concepts for the RFC persistence needs with
> the how-and-where they get their data being the lower level
> implementation stuff that can be done as a cleanup and consolidation
> of the current proprietary forms. Substituting a different file-format
> including XML thus becomes a second trivial step to be done as needed.

There is just one "proprietary" form. The .ini format of registry.c.

> Note as well that the backwards compatibility issues with older file
> formats become essentially a no-opt because the code for processing
> older formats exists and hopefully is just another of the options to
> choose from.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa