Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[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: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Server from Client
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 5 Jan 2002 16:28:59 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sat, Dec 29, 2001 at 03:45:36PM +0100, Reinier Post wrote:
> The /show command is a hack; the information should be sent to the client
> automatically, without any command, and in terms of the C data structures,
> just like any information update from server to client, so the
> client can read it off locally whenever it wants to.
> 
> Likewise, the /set command (and any other command) should be a regular
> Freeciv update request packet.

Ack.

> The server command line lives in the server process so it doesn't actually
> have to talk over the network; it can update the relevant structures
> directly.  But conceptually this is just an optimization.
> 
> All /commands can be interpreted as requests to read the contents of certain
> C structs or requests to have them updated.  The abstraction layer would
> describe a fairly generic C struct updating language.  We have discussed
> this in detail.
> 
> Meanwhile I saw the KGames specs; all of what we're discussing here seems
> a pathetic attempt to take one step in that direction.  But KGames is
> already there, so isn't this a waste of time in the long run?

www.kde.org, SF and FM doesn't know about kgames. And google also only
have rpms. Where is this spec?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner


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