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

[Dirk Stoecker <stoecker@xxxxxxxxxxxxxx>]

On Tue, 23 Jan 2001, Reinier Post wrote:

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

[...]

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

We don't make such an radical change, but only make the return method
usable (as it is not acceptable in current form). In general we do replace
text messages by parsable data structure. Nothing else.

If there is someone able to modify the communication work and
restructure it, I have nothing against it. This proposal only addesses
the problems resulting in the current message transfer form.

A long term method may be to remove the user messages totally and create
event messages on client depending on the update-information send by
server. If this is finished our methods can be removed, but I think the
main problem is:
  - Our method will make not that much work and can be done nearly
    silently - some patches and it works, some more patches and more
    messages work, some more ... old generic message disappears
  - Completely restructuring that is great work and it will be hard to
    find anyone doing that.

Ciao
 ____  _ _  ____  _ _    _ _  ____
|    |  |  |    |  | \  / |  |    | the cool Gremlin from Bischofswerda
|  __   |   ____|  |  \/  |  |    | WWW: http://home.pages.de/~stoecker/
|    |  |  |       |      |  |    | PGP key available on www page.
|____| _|_ |____| _|_    _|_ |____| I hope AMIGA never ends to make fun!