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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Jan 13, 2001 at 10:32:38AM -0700, Brian Olson wrote:
> 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.

I would like the get an interface similar to:

    int {tile,player,city,unit}_get_attrib(int id, int key, int max_length, 
char *data);
    void {tile,player,city,unit}_set_attrib(int id, int key, int max_length, 
char *data);

as the user interface. If the some code on the client will puts the
data into a monolithic block to communicate with the server (which may
also use a monolithic block) fine with me.

> 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.

Since this function would get used a lot I can also picture
*_set_attrib returning nothing and if there is an error let
*_set_attrib handle it (abort). Error checking would just clutter up
the code.

> 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.

See my reply. Also if this proposed monolithic block is used only some
supporting code on the client will have to map <object type, id,
subkey> to an offset into the monolithic block. The server will only
have as much blocks as there are players.

> 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

Python.

> several pieces of data with an object. I'd use a struct, and
> set_attrib( id, sizeof(struct myData), someOfMyData );

Maybe I also misunderstood you. Suppose we have an bodyguard agent and
a auto-settler agent.  So both agents will allocate a key for the
object type "unit". This could be done in an enum. So there will be
SK_U_AUTO_SETTLER and SK_U_BODYGUARD. On an "classic" settler no key
is set. On a bodyguarded auto-settle settler both keys will be
set. And it may be possible that the value length grows at runtime
(settler received another job). So there is no easy way to map between
values and offset into the monolithic block except reserve the maximum
value length in the block. Think about an efficent communication with
the server. Regardless what I said above I looks like I now dislike
the block idea.

> 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).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Of course, someone who knows more about this will correct me if I'm
  wrong, and someone who knows less will correct me if I'm right."
    -- David Palmer (palmer@xxxxxxxxxxxxxxxxxx)