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

[Reinier Post <rp@xxxxxxxxxx>]

On Sun, Jan 06, 2002 at 07:20:50PM +0100, Per I. Mathisen wrote:

> However, come to think of it, we have already solved very complex argument
> parsing. It is possible to solve this in a very nice way:
>  - make all the server options into a ruleset

Very good idea, of course ...

>  - extend common/registry.c|h so that registry options can be changed
> while in memory (not just inserted as now)

Yes ...

>  - this ruleset is transmitted to clients like the others

The problem with these packets is again that they transmit fixed structs,
so they have to be changed (and all the code to deal with them) whenever
an addition to the tuleset is made.

>  - whenever a client desires to change an option, it sends a
> packet_alter_registry (char *option, char *changestring). the registry
> code parses it, the server checks cmdlevel, updates its copy, and sends
> a packet_alter_registry to all clients (on failure it only needs to send
> such a packet to the client that sent the former packet, to reset GUI)

Yes, very good idea.

>  - whenever the server starts a game, or the server ruleset is changed
> while in a game (should be rare),

Not anymore, when the turn timeout becomes part of a ruleset ...
but eben then, it typically happens only once in many turns.

>the server ruleset is (re)parsed

Acceptable.

>  - a gui dialog which is a registry options browser and editor needs to be
> written (somewhat like the windows registry editor) in the client
>  - helptext is put in <command>_helptext, should be one for each option
>  - min and max values is shown in helptext. the server refuses to set
> values outside valid range

As Raimar said, it's better, but not essential, to check at the
client end.  That way the GUI can prevent the entry of incorrect values.

>  - each [topic] gets a cmdlevel associated with it. options are grouped
> primarily according to cmdlevel
>  - the remaining options, those few that do not alter game options but
> do something else (like saving, quitting) can probably be reduced to (int
> OPTION_TYPE, char *arg) with a new packet_server_cmd, or something.
> 
> This solution is generic, upward compatible and will make a
> non-interactive server daemon possible.

Not fully upward compatible: in order to allow the client to 'see'
new server options you have to upgrade it.  (Well there is always
the /set + /show interface of course.)

> (If done properly, civworld could reuse this to enable editing of all the
> rulesets directly from civworld... now that would be nice.)
> 
> Yours,
> Per

-- 
Reinier