[Freeciv-Dev] Re: server console cleanup patch v2

[Reinier Post <rp@xxxxxxxxxx>]

On Sun, Jan 06, 2002 at 10:25:45AM +0100, Raimar Falke wrote:
> On Sat, Jan 05, 2002 at 10:02:44PM +0100, Reinier Post wrote:
> > On Sat, Jan 05, 2002 at 06:56:11PM +0100, Per I. Mathisen wrote:
> > > On Sat, 5 Jan 2002, Raimar Falke wrote:
> > > > Good question. Well. What do you want to achieve?
> > > 
> > > Two objectives:
> > >  1 -> Simplify console code, remove unused code
> > >  2 -> Make it easier to parse server output

[...]

> > The immediate question is the relationship between the command line 
> > interface
> > and the Freeciv binary protocol.  At the moment they are completely 
> > separate.
> > Technically it would be best to unify them, 
> 
> > but the problem with the Freeciv protocol is that it isn't
> > extensible, you can't add new server options without breaking the
> > protocol, older clients won't be able to set or read these options
> > when they are communicated in terms of the existing Freeciv
> > protocol.  The only way out of this is to add support for this in
> > the code (not easy) or continue to use text and go the rfcstyle way.
> 
> I don't see this as a problem just add packets to do:
>  - request the list of all options the server know; void -> string list
>  - query an option; string -> min,max,default,current value,descr
>  - set an option; string, int -> void or an error code

That's a hybrid solution.  The 'show' packet is superfluous if you send the
response automatically every time an option is changed.  It's hybrid because
the response would still be text to be parsed at the client end.  BTW this
packet is already being sent for the GUI 'show options' menu items, it just
isn't designed to be parseable yet.
 
> These are a fixed amount of new packets (at most 6).

With this hybrid approach, only one is required: the /set packet.

> Note that options are identified by a string and not a number.

Yes, that way you continue to use 'commandese' as the language, strings based
on English.  This is the way it is now.  Using numbers, the translation would
happen at the client end, which would mean you either need to upgrade the client
to support new options, or support the option to make the client fetch textual
names for identifiers from the server.

-- 
Reinier