[Freeciv-Dev] Re: notify_player rewrite

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

Reinier Post <rp@xxxxxxxxxx> wrote:

>    Actually I was thinking of the support of client side
> server commands.  It was easy to add and it doesn't require any updating
> no matter what happens to the server side commands; all you have to do
> is register the command access level for new commands.  Whereas the
> server option dialogs, which use a special binary GAME_INFO packet,
> require server-side and client-side code patches to implement a
> protocol-breaking change to the GAME_INFO packet whenever a new server
> option is added.  This is because it encodes and decodes the C struct
> holding the server options.  This makes the addition of new server
> options a problematic thing to do.

To be pedantic, the server option dialogs don't access the client
GAME_INFO data, instead they use the "report" mechanism, whereby
the server constructs the table and sends it to the client as a 
big string (plus title string etc).  (See page_conn_etype() (was 
page_player_generic()) in server/plrhand.c, PACKET_PAGE_MSG.)  
Ie, essentially the method you are advocating.  

But your general point remains valid -- just a poor example :-)

Well, the above is ok in this case because the dialogs are only 
for human consumption.  If the client code itself needs to 
_understand_ some new server option, then it has to be added to 
GAME_INFO (or somewhere) and appropriate compatibility checks used.

Because of the above way of doing things, having client-side 
localisation of such "report" type messages is one area which is 
not fixed by modifying the notify_player() stuff.  (But this is 
not necessarily a point against changing notify_player(), depending 
whether/how we address this issue...)  (Localisation of replies to 
chatline server commands uses notify_conn as a base, so I'm not 
sure about that case.)

I do agree that the issue of compatibility when adding new messages 
in future needs to be considered in any new scheme.  Adding messages
happens often enough that we don't want this to force a compatibility 
break, or even too much overhead in terms of capability strings etc.
It would be nice for older clients to at least see untranslated 
messages in such cases, which suggests to me that sending the
string (or some sort of format string - eg, very restricted and
strongly checked printf-like) is still a good idea even if each 
message has an unique integer id.

OTOH, I don't think doing gettext-style keying on the text string
is a good idea, as this requires rather tight synchronisation between
the server and client to be successful.  That is, messages tend to be
re-phased, grammar/spelling corrected, or otherwise modified, often
enough that this would be a problem I think.

-- David