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

[Andrew McGuinness <andrew_mcguinness@xxxxxxxxxxx>]

2 Queries/niggles:

1)

I am not sure about using any string as a "message identifier" - I can
envisage a situation where there are many clients outside the "official"
freeciv tree, and they would all have to be modified to handle a small
cosmetic change to the message string.

If the "category" does not specify the message exactly, there should be
another field to do this.

This won't matter in the short term, when the protocol is likely to be
evolving, but IMHO an aim should be for the protocol to be as stable as
possible, so that slightly out-of-date AI/ AI-assisted clients can work.

2)

Was there not also an idea of identifying the client-originated packet
that triggered the server-originated packet (when applicable?) It is
likely to be possible for the client to work this out, but it should be
easier for the server to keep hold of it.

Andrew


On Tue, Jan 23, 2001 at 01:16:32PM +0100, Raimar Falke wrote:
> 
> Hi,
> 
> These are our ideas for the new event handling.
> 
> Overview
> ========
> 
> The following data is required by a client which is used by a human:
>  - the localized format string
>  - int arguments
>  - string arguments
>     * strings which maybe modified (city names, player names)
>       [maybe translated or not, e.g. city names possibly will get
>        translatable by client option]
>     * strings which stay equal and are translatable (names from the ruleset)
> 
> A non human client needs:
>  - a non-ambiguous way to identify a certain message
>  - the category of this message; the categories should be organized
>    hierarchically
>  - int arguments
>  - string arguments
> 
> There are certain ways to sent this data to the client. We (Dirk and
> Raimar) came to the following conclusions:
>  - the server sends the untranslated (english) format string; the
>    client will translate the string using gettext() to get the
>    localized format string
>  - int arguments aren't a problem
>  - strings which are changable: the server sends the type (city, player),
>    the verbatim name and the id of the city or player (the id is
>    required for the non-human client)
>  - strings which stay unchanged: the server sends the type (unit,
>    government, improvement,...) and the id; the client will lookup the
>    string (using "find_*(id)->name") and translate it with gettext()
>  - the non-ambiguous way of identification is the untranslated format
>    string
>  - the hierarchical category will be coded into an integer
> 
> Server side
> ===========
> 
> The call would change from:
> 
>   notify_player_ex(pplayer, punit->x, punit->y, E_NOEVENT,
>                    _("Game: %s unit has no moves left to add to %s."),
>                  unit_name, pcity->name);
> 
> to (slightly changed to be more salutary)
> 
>   notify_player_ex_new(pplayer, punit->x, punit->y, 
>                        make_category(CAT_FAILURE, CAT_UNIT, CAT_MOVE, 
> E_NOEVENT),
>                        N_("Game: %s unit has no moves left to add to %s."),
>                        AT_UNIT_NAME(punit->id),
>                        AT_CITY_NAME(pcity->id));
> 

[...]
-- 
Andrew McGuinness     Luton, UK        andrew_mcguinness@xxxxxxxxxxx