Re: [Freeciv-Dev] capabilities, was Re: space race patch

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

Mitch Davis wrote:
> David Pfitzner wrote:

> > Also non"+" entries really need
> > per-client capability strings in the server to be useful.)
> 
> This is a major weakness of the current capability code.  At the
> moment, the server can only find out about the capabilities of the
> most recently connected client!! :-(

It seems to me the client capability strings should be stored
in the connection struct.  It seems appropriate, and probably 
makes for convenient access, and if someone implements the ability 
to have multiple clients connect for a single player, it will do
the right thing and have per-connection capabilities!

> In my opinion, the game struct should have the capability in it,
> and the capability string should be saved with the game.  Then
> when it's reloaded, the server can check to see whether the
> potential client is capable of handling the features that the
> previous client had.

I'm not comfortable with this.  It seems to me the capability 
strings should describe (and be associated with) the server and 
client (ie, the executables) and their interaction, and not be a 
property of the "game". [1]

That means you can start up an enhanced server with an "old" savefile,
you get all the new capabilities of the new server.  Though naturally 
when loading an "old" savefile the appropriate thing to do (and what 
is mostly done currently) is to turn off (or set to backward-compatible 
defaults) any missing options which control the new features.  

The way savefiles is currently done with savefile_options (and 
secfile_lookup_int_default etc for small things) I think is better 
than trying to use the capability string, because what's in the 
savefile may change without changing the protocol (ie the client-server 
interaction).  (Eg, new server options which don't affect the client,
eg, new PRNG parameters. [2]).

-- David

[1] Though since you're the author of capabilities, maybe I'm just
misinterpreting or hijacking their real purpose :-)

[2] Hmm, that means the new PRNG should really be in server/ rather
than common/ ?  I guess you don't really want the client to use the 
PRNG anyway because it won't be initialized properly...