[Freeciv-Dev] [RFC] Replacement for current events

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

Hi,

There are two problems which are related in some way:
 - the current event system is bad. See the thread
   <http://arch.freeciv.org/freeciv-dev-200008/threads.html#00233> for
   reasons.
 - it would be nice for a client side non-human agent to know in every
   case exactly the outcome of a requested command.

I would like to address these two problems together. It would also be
possible to split the issues and handle them separate.

Proposal
========

The following must be transfered to enable the client to display a
string message: x, y, event, int arguments, string arguments
(ignoreing float numbers since they can be expressed as integers). An
extra result code is needed is needed for the second
requirement. However the event type and result code can be merged
(lets call it msgcode). To allow an easy detection on the client side
the the space of possible msgcodes has to be structured. Top level
spaces could be ERROR, SUCCESS and INFO. Each of these can contain
more subspaces like INFO_CITY and INFO_WONDER or actual
msgcodes. There should be exactly one ERROR or SUCCESS response per
request.

There has to be enough information in the response packet to allow the
client to match a response to a request. A possible solution is to add
a serial number in the request and so in the response. To be exact it
hasn't to be a serial number just something which the client can
reliable match. The server will not touch this number.

To allow a smooth transition there has to be a new interface besides

  void notify_player_ex(const struct player *pplayer, int x, int y,
                        int event, const char *format, ...)

which would be something like this

  void notify_player_ex2(const struct player *pplayer, int x, int y,
                         int msgcode, int number_of_int_args,
                         int number_of_string_args, ...)

There server has to know the number of arguments to get the arguments
out of "..." (there is no format string)(the int arguments have always
to be specified before the strings). Possible calls are:

   notify_player_ex2(pplayer, -1, -1, INFO_WONDER_GREAT_LIBRARY, 0, 1,
                     advances[i].name);
   notify_player_ex2(pplayer, punit->x, punit->y, SUCCESS_MOVED, 4, 0,
                     src_x, src_y, dest_x, dest_y);

Packet format
=============

Since there where conserns about wasting too much bandwidth submitting
empty strings I would make the packet length variable. So the wire
format of the new packet would be:

  struct wire_packet_event2 {
    int serial, x, y, msgcode, number_of_int_args, number_of_string_args;
    int int_args[number_of_int_args];
    char string_args[MAX_LEN_NAME][number_of_string_args];
  };

The strings can also be of variable length. Is this needed?

Client handling
===============

Just pass the format string together with the args to vsnprintf(). In
a transtion phase this string can be given to
client/packhand:handle_chat_msg().

Problem: the format string has to in sync with the server side
supplied arguments. Maybe some scripts could help solving the problem.


What do you think? Is there something missing?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "A common mistake that people make, when trying 
  to design something completely foolproof is to 
  underestimate the ingenuity of complete fools."
    -- Douglas Adams in Mostly Harmless