[Freeciv-Dev] Re: [RFC] New event handling

[Reinier Post <rp@xxxxxxxxxx>]

On Tue, Jan 23, 2001 at 01:16:32PM +0100, Raimar Falke wrote:
> 
> Hi,
> 
> These are our ideas for the new event handling.

I have thought about this too, and there was a basic question your
analysis doesn't address, namely, what is the Freeciv protocol really
supposed to do?  As I understand the freeciv_hackers_guide.txt, the
original idea was this:

 - the Freeciv game engine is a data structure of Freeciv objects
   (of type game, unit, city, etc ...)
 - the data structure (a network) is implemented by the object
   attributes, which can be plain integers or strings, but also
   references to other objects and lists of such references
 - actions in the game engine can really be viewed as object methods,
   for example, move a unit, and test routines to implement the constraints
   imposed by the game's rules (but an object oriented approach is not
   really carried through very strictly here)
 - the player-visible part of this object structure is maintained at both
   the client and the server side
 - the Freeciv protocol is asynchronous:
    - client->server messages are either actions (actions allowed by
      the game engine, they can be rregarded as object methods)
      or information requests (explicit requests to provide the contents
      of a particular object)
    - server->client messages provide the contents of Freeciv objects,
      or larger fragments of the Freeciv object structure

Initially, game engine actions could be performed at both sides, and
the protocol was only there to synchronise the results; this is not a
very good idea because actions carried through on the client may fail
on the server, so you'd need a good undo.  Later, the client would no
longer execute game engine actions locally, but only request such
actions from the server, expecting the server to send updated Freeciv
object contents in response as appropriate.  The basic approach to
server->client messages still is, as far as I can see, that they have
the purpose of sending the contents of Freeciv objects in order to keep
the client side data structure up to date, and nothing else.  There are
exceptions, such as the user messages.  In your proposal, this
exception would be the basis for *all* your information, and you drop the
idea of letting the server->client messages be a way to keep the common
object structure up to date.  I can see your reason for doing this: in
the existing protocol you are not guaranteed to get feedback on the
results of a requested action: if a unit move fails it may do so
silently, without even returning the explicit information that there
was no change in the unit's position.  But does this mean you need
such a radical change to the way the protocol works?

-- 
Reinier