[Freeciv-Dev] Re: extremely preliminary server command parsing

[Justin Moore <justin@xxxxxxxxxxx>]

> >    It seems we have several people working on the server upgrade and
> > unification portions.  There's some overlap (like with various split
> > functions), and it seems like there isn't too much peer review going on.
>
> I see your point here, and the lack of review is a little
> worrying.  Hopefully it's a temporary phenominon.  Duplication doesn't
> look too bad, AFAICS it's limited to the too split functions, which are
> pretty different.  I don't think I've duplicated any of your work here.

   The thing is I'm not really sure we need two split functions.  I think
one will do fine, provided we don't try and come up with too complex of a
syntax.  If we have to write customized split functions for some syntax,
it's probably too complex (IMHO).  We could impose some very simple
restrictions on syntax that would make parsing much easier, such as:

- blank lines or lines whose first character is a '#' are ignored (done)
- lines with a '\' as the last non-whitespace, non-commented character
    indicate a line continuation
- lines that end with a newline end a comment (this includes line
    continuated commands)
- if a file does not end with a newline (the last valid line contains a
    continuation) return an error

   While we don't necessarily need to create commands with our parsing
functions in mind, we shouldn't make them *too* complex to parse.

> As I write this, it occurs to me we may have a legacy code problem.  Is
> there anyone currently active who really knows the present server
> structure?  There doesn't seem to be for the AI, and pieces of the warmap
> seem to be mired in speculation.  Of course, I could be totaly wrong about
> this.

   I'm working on it (at least the command interface stuff).  It's a mess.
The basic structure (current) is "If it's a command, it's in stdinhand.c
... most likely ... or it could be in another server/*.c file ... but most
likely it's in stdinhand.c ... I think."  After the code rearrangement,
I'd like to attack the problem of people writing somewhat obfuscated code
that's already been encapsulated in a function, they're just not using it.

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx