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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

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
> > 
> > >                text
> > >    controller <-----> server command line         binary
> > >                       server core            <-------------> client
> > >
> > > If client and controller are the same program and the client is
> > > connected the commands and replays can be done on the normal binary
> > > protocol. However you would need to use the text interface if the
> > > controller is standalone (maybe however in this case it can just
> > > create a "dummy" binary/client connection) or the client isn't
> > > connected yet to the server (can be solved by connecting the client).
> > 
> > I think we can safely introduce the limitation that the controller will
> > always be a client with another, binary (as you call it) connection to the
> > server. So, yes, we can code it so that the controller can use the binary
> > connection to control the server (as Reinier suggested). This is IMHO also
> > the most "proper" way of doing it, and should probably replace the server
> > command line totally (making it a server daemon).
> 
> I agree; moreover, I think the controller should be a limited client.
> There is no need to make two connections.  I also think having a normal
> (stdin/stdout + readline) chatline interface on the client would improve
> useability a lot.  Then all you need is a /say command in the server and
> some trivial option to control whethr lines without / are interprted
> as /say commands and the server commandline and chatline will be 100%
> identical!
> 
> 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

These are a fixed amount of new packets (at most 6). Note that options
are identified by a string and not a number.

> > However, parsing rfcstyle is a lot simpler.
> 
> In the short run, yes.  If the syntax becomes more complex and people want
> client-side localization for the server setting interface, possibly not.
> 
> > I want to know what way we should go. If we are not going to use rfcstyle
> > for server control, I can remove rfcstyle and simplify the console and
> > server reply code a lot.
> 
> Without good code to make the binary Freeciv protocol generic and upward
> compatible (that is, a server would be able to teach an old client about
> a new server setting on the fly) I think using rfcstyle is the best idea.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner