[Freeciv-Dev] How my book describes the Freeciv data architecture

["Eric S. Raymond" <esr@xxxxxxxxxxx>]

Just replying to Jason's comments about my book's description of the 
data architecture here.  Discussion of my proposal is under a separate thread.

Jason Dorje Short <vze49r5w@xxxxxxxxxxx>:
> ><para>To resolve this conflict, notice that it's the server's job to
> ><emphasis>use</emphasis> the registry data, but the task of carefully
> >error-checking that data could be handed off to another program to be run
> >by human editors each time the registry is modified.  The ideal Unix
> >solution would be a separate auditing program that analyzes the source
> >of the server code to determine the set of properties it uses, parses
> >the FreeCiv registry to determine the set of properties it provides,
> >and prepares a difference report.</para>
> 
> I don't think the ideal unix solution would do any source code analysis. 
>  This seems to fly in the face of all concepts of simplicity.

The tool I have in mind wouldn't be a decompiler or anything, just 
something that recognizes icon-retrieval calls with a pattern-match.

> IMO (though I am not an expert), the unix design would be where the 
> ruleset format was a well-specified standard, and a completely 
> independent program would be able to verify this.

Noted: will add as a possibility.
 
> In a world of changing ruleset formats, the freeciv solution would 
> probably be to add another (small) file server/verify.c, and have this 
> file (linked with the rest of the server code) compile into a "verify" 
> program to do the work.

Agreed.
 
> As an aside: it sounds to me like you're confusing the server and the 
> client a little bit.  The server reads the ruleset data, and sends some 
> of it to the client as needed.  The client reads the tileset.  But much 
> of the tileset depends on the ruleset data - for instance the ruleset 
> specifies the name of the sprite to use for each unit.  This is sent to 
> the client when the game starts, and consequently the named sprites 
> cannot be initialized before then.

Thanks for the correction.  I have changed the last paragraph to:

<para>The performance impact of data file parsing is minimized because
for each file the operation is performed only once, at either 
or client server startup time.</para>

> The system used is in some ways very elegant.  We load all sprites and 
> put them into a hash based upon their name.  Then when we receive the 
> ruleset data all we have to do is look up the proper sprite for each 
> element.  Most of the ruleset elements have two tags specified - a 
> primary and an alternate - so we can fall back to a default if 
> necessary.  To some extent, this allows things to work even though 
> modpacks and tilesets are distributed separately (for instance, a "Lord 
> of the Rings" modpack may come with a supporting tileset with special 
> graphics, but the alternate sprite names provide fallback graphics if 
> "standard" tilesets are used).
> 
> But the system does have drawbacks - for instance it is difficult or 
> impossible to free any "unused" sprites after we're done loading sprites 
> - first of all since we don't really know _where_ they may be used 
> (sprites may be used multiple times, or none at all, depending on what 
> the ruleset specifies), and secondly since there's always the 
> possibility that we may later connect to a server with a different ruleset.

How you deal with the deallocation and damespace-matching problems is,
fortunately, out of scope for this cases study. :-)  I'm writing about
data transparency here.
-- 
                <a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>