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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Jan 06, 2002 at 04:59:44PM +0100, Reinier Post wrote:
> 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.

Ok. But than the server has to sent all options when a client
(re-)connects.

> It's hybrid because the response would still be text to be parsed at
> the client end.

The "min,max,default,current value,descr"-answer-packet would contain
these in a binary form.

> 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.

If we assume that the client program doesn't have to understand the
options in detail but only has to present them in a structured way to
the human it is sufficient if the client can fetch a list of the
available options from the server. If however the client will use the
options more (setting the map size based on the moon position for
example) it may be better (not necessary) to use integers as
identifiers for the options instead of strings. However than you have
the mentioned compatibility problems.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Python 2.0 beta 1 is now available [...]. There is a long list of new 
  features since Python 1.6, released earlier today. We don't plan on 
  any new releases in the next 24 hours."
    -- Jeremy Hylton at Slashdot