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

["Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Aug 20, 2003 at 10:30:22AM -0700, Rafa³ Bursig wrote:
> On 2003.08.20 18:55, Mike Kaufman wrote:
> 
> This can be partialy fixed by changed idetification method in my net 
> support. Curretn I want make it as simple as can and I use int field as 
> option idx in packet. When you remove or add new option then you 
> corrupt old clients (without capabilities changes) but this can be easy 
> fixed by changed int id to string id (option name as id) in packet. In 
> this case old client simple ignore new options and don't corrupt with 
> removed ones.

capabilities changes for this is unacceptable.
 
> There will be only problem with type changes becouse name be the same 
> and server and client will have different type of varaible. In this 
> case we should use different options name with such changes.

what's clean about this?
 
> Sharing options struct will give you this advances that you know all 
> options before connection(server start) and you can simple start single 
> player server with all options canges at one call. This give you nice 
> clean code that do it.
 
If this is the only reason to do this: no. There is nothing to starting a
server with fork() and then sending commands when sniff_packets() starts.
In fact that's what you're going to have to do anyway. And by that time,
all necessary packet traffic will have already occurred.

> This will be nice packet ;)

two packets actually (maybe three, one just for option state change.)

> > > How many of those vars will changed with different "rulesets" ?
> > 
> > no idea. so what?
> how many of those variable will be changed with different "ruleset" or 
> modpack or other enviroment settings.
> How often we will have situations that number of options , type of 
> options , name of options , etc... will be changed ?

modpacks have nothing to do with it. This is a client/server game which
means that the client need not and does not know everything the server
does. Pubserver often has extra patches that apply different types of
settings that a run-of-the-mill home server never needs to have. Who's to
say that 1.15.0 pubservers won't have extra options? I can't. This is why
having a common struct that the client depends on for option definitions is
a bad idea. We've got a good network protocol. Use it.

> Mike my code exist and work (I will send fixed new vesion soon - string 
> packet option idx), if you don't like this implementation then please 
> MAKE BETTER, but please do it soon becouse I have ready code that need 
> such functionality.

These are necessary but not sufficient reasons to commit code. The
sufficient reason is mostly correctness. As much as I'd like this code to
go in (for selfish civworld related reasons), this is not the path we
should be going down. Also, I do not have time or inclination to write this
code. If you want it in, I've outlined the method. I don't dispute the
merit of the idea: the GTK connect dialogs also need this kind of
functionality.

-mike

PS: I don't think that all your work is in vain. I agree that the settings
structs should be moved into a header file, be in stdinhand.h or a new
command.h, but it should be sitting in the server/ directory.