[freeciv-ai] Re: FreeCiv brief analysis

[nikodimka <nikodimka@xxxxxxxxx>]

> > > Which part (the external program which is attached to the puppeteer
> > > interface or the common client) controls the puppeteer interface? 
> > > I.e. which part issues requests and which part responses?
> > 
> > huh? I don't quite get the question. :(
> > what do you mean saying "controls the interface" 
> > 
> > is it a terminology question?
> > I would say that external program issues requests and client issues 
> > responses.
> > 
> > The civclient openens the socket and decides when to close it.
> 
> Maybe this become clear if I show you the alternatives:
> 
> If the common client controls the interface 
> 
>   the common client would looks like this:
>     forever:
>       wait for packet
>       process packet (this updates the internal state)
>       notify external program
>        (if the external program returns here or unlock the common
>        client would continue and wait for the next packet)
> 
>   the external program may look like this:
>     notify_from_common_client_core():
>       lock common client
>       query client
>       calculate
>       issue commands
>       unlock common client
> 
> 
> So it boils down to where-is-the-mainloop. In the first scenario you
> however have to think about locking.

As far as I can tell the first scenario is closest to what is 
implemented now and what I want it to be.
The main loop is in the civclient. 

In regards of locking:

a human player does not ever lock the civclient? right?
so not every kind of an external program does need to lock.

Anyways I have to think the locking through a little bit more.
For the first look it seems that a pair of "lock" and "unlock" commands
would suffice.

> 
>       Raimar
> 


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/