Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2003:
[Freeciv-Dev] Re: (PR#5121) move server command structs/ids/help/etc to
Home

[Freeciv-Dev] Re: (PR#5121) move server command structs/ids/help/etc to

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bursig@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#5121) move server command structs/ids/help/etc to common code
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Wed, 20 Aug 2003 15:48:29 -0700
Reply-to: rt@xxxxxxxxxxxxxx

I think Mike brought up some important points regarding client <-> server
compatibility. This is hard to do right, although I symphatize with the
desire to have working code rather than the endless job of reworking
everything else to fit.

FYI: This is a subject which was discussed at length in December 2001 and
January 2002. Here is a post I made in that discussion:

" " " "

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.
...
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.)

" " " "

A bit ambitious, certainly. I set about to implement it, but did not get
very far before I stumbled into the AI code as part of my teams patch
work, and never got out again. The rest is, as they say, history...

What I did accomplish, however, was cleaning up the rulesets loading,
removing data/classic, adding "rulesetdir", implementing ruleset free
functions and the server reload functionality.

These were the remaining milestones:
 3 -> keep section_files in memory, and enable "ruleset <option> <value>" in
      civserver (and "ruleshow"). only for games.ruleset. load section_files
      early. reload when necessary.
 4 -> serialize and send rulesets to client, make gui that shows settings and
      changes to them
 5 -> move ruleset.c to common and rewrite rulesetloading to happen in both
      server and client. make gui able to change rulesets (in pre-game)
 6 -> move stdinhand.c etc to client/control/ as a new client. need new
      packet PACKET_SERVER_CONTROL also
 7 -> make --daemonize, which reads "server.ruleset", forks X versions of
      itself then quits, each reading its own [server_*] parameters.

I can expound on this at length if anyone is interested. I am not going to
finish it myself in the near future.

Yours,
Per

"The truth is there is an ideological struggle between those who believe
that the best way to grow the economy is to give more money to the
wealthy, and the Democrats who believe that the wealthy will make more
money if average people do better." -- Bill Clinton, November 2000




[Prev in Thread] Current Thread [Next in Thread]