[Freeciv-Dev] Re: [Patch] Attribute handling

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Aug 31, 2001 at 01:05:04PM +0200, Christian Knoke wrote:
> Am Freitag, 31. August 2001 12:02 schrieben Sie:
> 
> > > This is an updated version of the attribute handling stuff. From the
> > readme:
> >
> > -----------
> > Client/server model
> > ===================
> >
> > Each client player has an attribute block and the server also holds
> > such an attribute block for every player. All attribute blocks the
> > server holds are included in the save game. The client and server
> > synchronize their blocks. The server sends it's block to the client
> > at game start or reload. The client sends an updated block at each
> > end of turn to the server. Since the maximum packet size is limited
> > (to 4k) and the attribute block can have arbitrary size (although
> > limited to 64k in this version) the attribute block can't be
> > transferred in one packet. So the attribute block is divided into
> > attribute chunks which are reassembled at the receiver. No part of
> > the server knows any inner structure of the attribute block. For the
> > server an attribute block is just a block of bytes.
> >
> > User interface
> > ==============
> >
> > Since an attribute block isn't a good user interface the user can
> > access the attributes through a mapping/dictionary/hashmap/hashtable
> > interface. This hashtable will get serialized to the attribute block
> > and the other direction around. The key of the hashtable consists of:
> > the (real) key, x, y and an id. The (real) key is an integer which
> > defines the use and format of this attribute. The values can have
> > arbitrary length. The internal structure of an value is unknown to
> > the attribute handling.
> >
> > For easier access there are wrapper functions for the common types
> > unit, city, player and tile. So there are easy methods for attaching
> > arbitrary data to a unit, a city, a player (self or other) or a tile.
> > -----------
> >
> > If there are further questions please ask. If there are no comments
> > this patch will be applied in some days.
> >

First: attributes are independent of agents. Attributes general enough
to also be used by other client side things. For example: if
attributes would exists before worklists I would implemented worklists
using attributes.

> I hope we get more and more agents in the future, which should
> work together. So:
> 
> 1. If agents are added to the client, will it be compatible to
>    old games (with a different attribute block)? This is important
>    for testing.

No problem if the enums in client/attribute.h stay constant for the
existing users of attributes.

> 2. What about block size? Will it be enough in the future? 64KB
>    upload needs about 20 seconds with my 56K modem, and this
>    shall happen every turn, when the line is busy anyway. That
>    is too much.

64k is the maximum. In the initial discussion about this there were
also the opinion that the client only needs to sent the changes. It is
still possible to implement this without changing the user
interface. IMHO we should wait how memory hungry the agents turn out.

> 3. What's stored in the attribute block, aren't game facts (from
>    the game's point of view), but rather the players's intentions 
>    and commands for the future (which of course will differ from
>    player to player). Don't you feel that it's a better approach
>    to store these things local for the client, and find a way to
>    link it to the game?

Also attributes will/can hold immediate results. And hopefully also
experience. Yes it is possible to store this at the client but:
 - it is a hard to get the correct data for a given reloaded game
 - the client has no way currently to know when the server saved
 something and IMHO should never know this
 - in the medium term a way is needed to continue carring out actions
 on the server if the client disconnects. This can be done for example
 by spawning a helper client. Such helper client needs the intentions
 the original client had.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Premature optimization is the root of all evil."
    -- D. E. Knuth in "Structured Programming with go to Statements"