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

["Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>]

On Sat, Jan 05, 2002 at 10:02:44PM +0100, Reinier Post wrote:
> > I agree; moreover, I think the controller should be a limited client.

Why do we need a controller program separate from the client at all? I
think the perfect setup would be a client that can control everything the
server can do (if it has sufficient cmdlevel) and a non-interactive server
daemon.

> > I also think having a normal
> > (stdin/stdout + readline) chatline interface on the client would improve
> > useability a lot.

Possibly, but I'd be more in favour of adding GUI controls, and avoid CLI
wizardry as much as possible.

On Sun, 6 Jan 2002, Raimar Falke wrote:
> I don't see this as a problem just add packets to do:
>  - request the list of all options the server know; void -> string list
>  - query an option; string -> min,max,default,current value,descr
>  - set an option; string, int -> void or an error code
>
> These are a fixed amount of new packets (at most 6). Note that options
> are identified by a string and not a number.

Well, first, not all options are of int type. Second, some of these have
more than one argument too, opening the Pandora box of string parsing.
That is, if you are going to do anything with them (like controlling them
from a dialog window).

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
 - extend common/registry.c|h so that registry options can be changed
while in memory (not just inserted as now)
 - this ruleset is transmitted to clients like the others
 - 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)
 - whenever the server starts a game, or the server ruleset is changed
while in a game (should be rare), the server ruleset is (re)parsed
 - 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
 - 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.

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

Yours,
Per

"Oil industry spokesmen dismissed as "absurd" and "nonsense" allegations
by aid experts, veteran East Africa analysts and several prominent Somalis
that President Bush, a former Texas oilman, was moved to act in Somalia,
at least in part, by the U.S. corporate oil stake." -- L.A. Times