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

[Reinier Post <rp@xxxxxxxxxx>]

On Mon, Jan 07, 2002 at 12:05:17AM +0100, Per I. Mathisen wrote:
> On Sun, 6 Jan 2002, Reinier Post wrote:
> > >  - 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.
> 
> No. The registry dialog on the client end should be generic and display
> any registry info sent to it. I imagine it could be like Windows'
> "regedit" or MacOSX's NetInfo config tool. It might be a pain to code, but
> once that is done, making changes will be so much easier.

Yes, and I was trying to say, for that you need a different packet format,
with both the values and the attribute names.

Once you have that, the code on the receiving end must encode the data
structure not in the C struct but in an associative array, similar to
the settings structure in server/stdinhand.c but with a hash for the
attribute names.

> > >  - 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.
> 
> Yes, you are right, when I think about it. Also because it would be much
> better if min/max info is read from the ruleset, instead of hard-coded in
> the server. But I cannot think of an elegant way of doing it... best I can
> think of is looking for a *_valmin and *_valmax option for each option not
> in the set {*_valmin, *_valmax, *_helptext}, but like *_helptext, it is
> more like an ugly hack... I don't really like it.

I don't know, it seems acceptable to have a command like /set mintimeout 40
so perhaps min* and max* can be regular variables.  It's different for
variables that take file paths or player names.

> > 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.)
> 
> See above. I still maintain it is both upward compatible and makes /set +
> /show entirely redundant.
> 
> What do people think of making the server non-interactive anyway? A bad
> thing in principle, or ok if done properly?

It would be good to still have the cmdline interface in the server binary,
otherwise you need to start up two programs just to run a server.

> Yours,
> Per

-- 
Reinier