[Freeciv-Dev] Re: server console cleanup patch v2

[Reinier Post <rp@xxxxxxxxxx>]

On Sun, Jan 06, 2002 at 05:29:59PM +0100, Raimar Falke wrote:
> If we assume that the client program doesn't have to understand the
> options in detail but only has to present them in a structured way to
> the human it is sufficient if the client can fetch a list of the
> available options from the server. If however the client will use the
> options more (setting the map size based on the moon position for
> example) it may be better (not necessary) to use integers as
> identifiers for the options instead of strings. However than you have
> the mentioned compatibility problems.
> 
>       Raimar

Well you'd want to base the update interface on the value domain,
i.e. there can be a specific interface to set integers with a minimum,
maximum and default value.  The client can even learn the set of variables
with their types from the update packets it gets.

I'm not likely to code this, so it's just a suggestion for Per.

At the moment the server settings are transmitted in several ways.

1) the PACKET_GAME_INFO and PACKET_MAP_INFO packets.
As far as I can see they packet gets sent as early as needed to keep the
client up to date.  They pack and unpack 'struct game' fields, so they
have the incompatibility problem, breaking when new options are added.
They operate on game struct fields, not server options, and there is
no 1-1 correspondence between these.  Also, they do not transmit type
information (minimum/maximum value for integers, for example) and the
client doesn't actually know about this at all.

2) the text responses from the command line; these are sent in response to
a /show command, and arrive at the client end in PACKET_CHAT_MSG messages.

I think in the long run you wouldn't want to use either, but instead,
replace PACKET_GAME_INFO with a generic info packet that can not only
transmit the value of settings, but also their type info such as min/max
values, and modify the client to accomodate for these variables at
runtime.  This packet would use an RFCstyle textual output, but it
would not have the PACKET_CHAT_MSG opcode.  A second packet would be
a client->server packet with a set of update requests for server settings;
this packet can simply use the existing command line language as its format,
an alternative is to just use the existing way of transmitting /set
commands.

In the short run I think it would be best to add the new info packet,
replace GAME_INFO/MAP_INFO with it, and bring some of the setting handling
code from stdinhand.c to the client end to allow the type handling.
That code expects a fixed, known set of server options, but it already
accomodates type info handling and several other bits of information
about server settings that can be useful at the client end.  It allows
a quite intelligent GUI dialog at the client end, that would replace
the existing server settings dialogs.  After the GUI is in place,
the client can be changed to hold server settings in a completely
dynamic associative array; that would solve the compatibility problem,
but it is not very urgent.

What you decide you want to do is of course up to you, Per.

-- 
Reinier