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

[Reinier Post <rp@xxxxxxxxxx>]

On Tue, Jan 23, 2001 at 04:44:17PM +0100, Dirk Stoecker wrote:
> 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?

[...]

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

OK, let me rephrase my comment: I think it is an excellent idea, as
long as this parsable object structure is the representation of the
state of a server side object, and the server side object represents a
piece of game state - *not* the encoding of a 'response'.  It may
represent a piece of state that only the client-side AI knows how to
interpret, its state may even be changed from the client; but all state
info maintained by the server should be in the form of typed objects,
so the server can read its type from rulesets, and save and load its
contents to/from savegames just as it does for any other type of
object.  (The existing code still has some limitations here.)  That way
you can maintain the paradigm that server->client messages are the
contents of objects that represent game state or game state updates,
and client->server messages are requests to modify or show this state.

I think it is a mistake to view server messages as responses to
client requests.  The real logic is reversed: the server updates the
game state at the client side, and the client may respond with
requests to the server as a result.

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

This is exactly what happens, not just for user messages, but for all
server->client messages.  It would be good to convert the text messages
to parsed data structure as well.

What I object to is the addition of a hack to make them seem responses
to client requests - you can't base reliable client-side AI programs on
that approach, it is broken by design.  Whereas, if you program the
client side AI according to the existing programming model, namely,
in terms of routines triggered by updates from the server, that generate
requests to the server, your client-side algorithms will be more
difficult to understand, but they will actually work.

-- 
Reinier