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

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

As background for the XML discussion ...
  http://java.sun.com/developer/EJTechTips/2004/tt0527.html#1

C is not a primary area for XML co-development and may not have
as much support for doing things as other language or development
environments. One should consider whether this has bearing on
whether this needs to wait a major release and major development
strategy shift, can be done with auxiliary utilities or a shift
to a dual mode code development like C-Perl.

But looking at the full scope of possibilities in an environment
that is more active in building/using such tools and features is
certainly something to do.
=====

As a quickie answer to Anthony`s question on whether XML could
in anyway be considered a Freeciv requirement as opposed to
yet-another-fashion-upgrade-of-computer-kids-in-training, a
key question to answer besides having someone kickstart the real
process by doing an RFC and prototype patch, is whether Freeciv
wants to gamble on the longterm viability of the XML attempt to
come up with a universal data exchange format as opposed to similar
ones done at the time of initial Freeciv development that clearly
have not made it. The proprietary solutions used by Freeciv, while
requiring their own code development, do allow one to customize the
process, presenting everything from a user friendly to data-centric
solution as required. Converting to XML requires one to follow the
standard which in this case is ascii (human readable-editable) but
generally not as simple to edit manually because of language rules
and requirements do result in some picky noisy flavour.

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.


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.

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.

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.

Cheers,
RossW
=====