[Freeciv-Dev] Re: [RFC] Attaching information to objects

[Brian Olson <locke@xxxxxxx>]

On Saturday, January 13, 2001, at 09:25 AM, Raimar Falke wrote:
> The users of this let-the-client-save-some-state thing are interrested 
> in attaching them to a certain object (unit, city). However you 
> mentioned something I missed: saving data in general. The client side 
> ai/scripts may want to just save some state. One and the presumably 
> easiest solution would be to let them attach this data to their own 
> player. 

All this is good.

> If you only provide one large memory block for every client the 
> clients have split them manual. 

Yes, and that's not a bad thing. It keeps the server simpler, and reduces 
traffic to the server. Even with the client caching and never needing to _get_ 
from the server except at reconnect, a busy AI may update the auxiliary data 
for everything several times per turn. The client's cache would have to become 
slightly delayed in its writes to the server, at most flush the dirty entries 
once per turn.

Indeed a monolithic block could be emulated by just adding data to the 
self-player object, except for the limits imposed later...

> > > The interface could be: 
[snip!]
> So I'm in favor of an interface like  
>    int get_attrib( int key, int max_length, char *data); 
>       return value is set/unset 
>    void set_attrib( int key, int length, char *data); 
>  
> The length of the data has to be limited (256, 512 or 1024 bytes). 
>  
> The implementation will now have to manage these memory regions. This 
> isn't nice in C but IMO the easy interface is worth it. 

Agreed. Those look like good functions to use. Shouldn't be more than a couple 
hundred lines to implement. set_attrib should return int, being either an 
error/success code, or the actual size written (user left to decide that return 
< length is an error). Could be both: 0..MAX_HASH_DATA_LEN is length written, 
-1..MIN_INT error condition.

Falk raises a good point (or maybe that wasn't the point and it made me think) 
that it may be reasonable to have only a single hash per client, not per 
unit/client. Some form of mangling to use unit_id as the hash key. Perhaps use 
the high 2 bits to differentiate between unit/city/player/other OR'd with the 
id as the hash key. If you need to associate multiple pieces of data with a 
single unit, either play with a couple more high bits, or build some sort of 
structure into the data block in the hash. If you don't want to play with high 
bits at all, maybe one hash for each of all unit/city/player/(other) against 
the id of each.

Having come to this point in thought, it seems needlessly extravagant to have 
players*objects hashes in the game. I suppose I shouldn't make assumptions 
about others' coding styles, but in any language other than perl a hash 
wouldn't be the way to associate several pieces of data with an object. I'd use 
a struct, and 
set_attrib( id, sizeof(struct myData), someOfMyData );

If there is there is a unified hash per client, then one could have an overall 
quota of size rather than limits per submitted chunk. Also, the unified hash 
could be kept purely on the client side and submitted to the server as a single 
block of data (there I go again).

[insert clever signoff here]
Brian Olson http://bolson.org/