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: Reinier Post <rp@xxxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Server from Client
From: Daniel L Speyer <dspeyer@xxxxxxxxxxx>
Date: Fri, 28 Dec 2001 01:00:47 -0500 (EST)

On Thu, 27 Dec 2001, Reinier Post wrote:

> On Thu, Dec 27, 2001 at 06:53:52PM +0100, Reinier Post wrote:
> > 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.  [...]
> 
> > 2) The second way is to use the special 'reporting' packets that send the
> > current settings as a text string, and parse the text.  [...]
> 
> > 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.
> 
> But Per's rfcstyle solves this problem.  So this seems to be the best way
> for the moment.

Unfortunately, it doesn't.  An extended version of it might.

I recently tried it for checking when a user had connected, but it was all
the same '012' as tons of other messages.  I haven't looked at what would
be needed to expand rfcstyle to what's needed.

What's needed is really something of a mess.  As I see it, it is nessesary
to use C's string handling and raw unix io to both find the reply to our
question (with potentially anything having been printed since we
asked) and then to parse it in spite of numerous free-form strings.  I'm
starting to seriously think that every query should have a unique flag
that the server echos back with the answer.  Does anybody have experience
with this?
 
    
--Daniel Speyer
"May the /src be with you, always"



> 
> -- 
> Reinier
> 
> 



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