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

[Reinier Post <rp@xxxxxxxxxx>]

On Fri, Jan 26, 2001 at 08:21:12PM +0100, Raimar Falke wrote:

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

Yes, to sync the state of the client from the server.

>You would also like it
> if every response (server->client packet) is a copy of the server
> state. Is this correct?

Yes, such packages usually contain the state of objects that the
server and the client both know, or changes to the state.  (For
instance, the deletion or creation of an object.)

I would like it not to be seen as a response!  Packets sent
by the server can be seen as 'responses' when they result from code
triggered by the server receiving a packet from the client - for
instance, a unit movement request results in the new position of the
unit being sent.  This is because the server is single threaded and
I'm not sure it is a good to see it as a *design* feature which
I don't think it really is.  The same packets may also be sent when
something else causes the state to be updated.

> Some things like {unit,city,tile,player}_info follow your
> paradigm.  However the current event handling doesn't.
> However the current event handling doesn't. An event

I don't understand what you mean by 'event handling'.
Things like unit movement or barbarian appearances
do follow this paradigm.

> 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 do not see how that is an exception.   I can't follow you, sorry :(

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

I don't understand; I already pointed out the fundamental technical
problems with writing client side algorithms that behave *as if* they
can reliably know state information that really exists only at the
server side.

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

Sorry, yes that was my pojnt: I think hat would be a great step forward.
 
> > 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)

That is, they will turn this into a design feature of the game.
At the moment you can still look upon the server as event driven
*internally* although it really isn't.

> of the former
> request. It will be very easy to implement event driven code for the
> client.

I think depending on return codes will only make it harder.  Plus there
is the problem of having to teach the server which return codes to
produce (if you want a dymanically extensible system).
 
>       Raimar

-- 
Reinier