Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: Server from Client
Home

[Freeciv-Dev] Re: Server from Client

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Daniel L Speyer <dspeyer@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Server from Client
From: Reinier Post <rp@xxxxxxxxxx>
Date: Thu, 27 Dec 2001 18:53:52 +0100

On Sat, Dec 22, 2001 at 01:42:41PM -0500, Daniel L Speyer wrote:
> I've been working a little on putting server controls into the client GUI,
> and have been running into trouble getting the needed data.  Is there a
> way for the client to request just the value of a config variable, or just
> its max/min?  The Show Server Options menu commands just get a single text
> string, which would be very annoying to parse.
> 
> Is there a way?  Would it be reasonable to add a way?

There are three ways that I'm aware of.

1) Closest to the Freeciv design: let the config vars be
part of the data structure shared between server and client,
and make sure they get updated upon any change by regular updating
packets from the server.  The problem is that you have to change such
packets every time a config var is added or changed, breaking the protocol.
The proper way to solve this I think is by making the protocol generic.

2) The second way is to use the special 'reporting' packets that send the
current settings as a text string, and parse the text.  I think the
whole existence of these packets is a case of broken design, which can
only be understood by the fact that it doesn't suffer from the
compatibility problem of the previous method.  This is because the
text is *not* parsed except by the human eye - so if you start
to parse it in the client, you have a doubly broken design.

3) The third way is to use the server command language: /show <var> or similar.
Extend the language as necessary.  This method has already been discussed.
However, we only discussed the language to use for the command, not the
language of the command results.  At the moment, there is no restriction
on the form of the results, because they are intended for human
consumption; the same problem as with method #2.  You would would have
to formalise it in order to reliably parse it in the client.  (There is
already software which parses civserver command line output, but civclient
doesn't do it.)  You can make this work but the fact remains that text
really isn't the best medium for information to be passed between server
and client, as Per Mathisen pointed out some ages ago; it would be better
to pass C structs and generate all text at the client end.

So I think the ideal solution is a generic form of 1, but you can also
try 2 or 3 if it is done tidily.

> --Daniel Speyer
> "May the /src be with you, always"

-- 
Reinier


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