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

[Reinier Post <rp@xxxxxxxxxx>]

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.

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

> Yours,
> Per

-- 
Reinier