[Freeciv-Dev] Re: notify_player rewrite

[Reinier Post <rp@xxxxxxxxxx>]

On Thu, Aug 10, 2000 at 10:05:10PM +0200, Per I. Mathisen wrote:
> On Thu, 10 Aug 2000, Reinier Post wrote:
> > You're proposing an improved gettext, but with an as-yet-unknown,
> > Freeciv specific, compact and binary source language (defined in terms
> > of C data structures).
> 
> I am not suggesting 'improving' gettext in any way. I am suggesting moving
> the text messages from the server to the client.

What I meant to say is, you would effectively be designing a new language
for these messages.  A very simple one, of course.  But the work of first
specifying the message in terms of that 'language' and then translating it
(to text in the client's language), is still there.  It won't necessarily
be easier.
 
> > An XML-based protocol ...
> 
> You know what would be nice? Corba for network, XML for rulesets and 
> glib for hashes&lists. But let's not digress (unless you volunteer).

No, I don't.  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.

And unless I'm not thinking right (which happens all the time),
you're proposing to introduce this mechanism for notifications.
I would rather get rid of it!  If the client really can't do with
gettext or ad-hoc parsing of messages, but actually needs the structured
information the message represents, then it would be a good idea to
add support for sending this information in a way that allows for
extension without having to manually add fields to structs and
packets.  This can be done by sending structured text (XML) that is
parsed into dynamically allocated structures at the receiving end.
Since XML would be useful for other purposes, I think it would
be a better long-term investment than your proposal.  That's all.

> [in another post:]
> >The server could record the language of each client, perhaps as a
> >connection field, and internationalize its messages accordingly.
> >Gettext appears to support this.
> 
> I do not see why the server should send text to the client during
> gameplay.   We would have to parse the received text to pull out the
> variables necessary for sound and client ai support. That seems 
> backwards to me.

I hope you see now: extensibility.

> Yours,
> Per

-- 
Reinier