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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Jan 26, 2001 at 06:52:14PM +0100, Reinier Post wrote:
> 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 don't understand it fully. Let me try: You don't like point of view
that the client sends request and the server responses with 0, 1 or
more packets. You would like to see the communication as a way to sync
the different states of the client and server. You would also like it
if every response (server->client packet) is a copy of the server
state. Is this correct?

Some things like {unit,city,tile,player}_info follow your
paradigm. However the current event handling doesn't. An event
handling which will follow this paradigm would be an
client-generate-event system like mentioned below. But also such a
system would have its exceptions: "Nation foo has started building
wonder bar". Such a system would be nice but is not our task.

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

This point is fishy IMHO. For you the server drives the game for me it
is the client. Technical there is no difference.

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

The new system will provide data in structs to the client additional
to the text message (the format string to be exact). However I'm not
sure if this was your point.

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

The new system will allow you to add a callback to a request
(client->server packet) which will be called if there are packets
coming from the server which are results (more exact which are
generated during the processing of the request) of the former
request. It will be very easy to implement event driven code for the
client.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."