[Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)

[Reinier Post <rp@xxxxxxxxxx>]

On Sun, Sep 30, 2001 at 11:09:42PM +0200, Raimar Falke wrote:

> > > > A distinction must be made between pointers and their values
> > > > (usually objects or lists).  This is only important when a
> > > > pointer is used as the right hand side in an assignment:
> > > > 
> > > >   set "Dresden".worklist = "Leipzig".worklist
> > > 
> > > Do we really need such constructs? I agree that there are some
> > > problems if such powerful constructs are introduced.
> > 
> > They will be needed to express savegames.
> 
> I'm not sure if this is a good idea. Why? The server
> variable-or-ruleset problem is a real one. It is ok if the savegame
> will hold the unified parameter (whenever form they will finally
> have).

It's easier to use a single language for everything.
That way, if the language is extended, you benefit everywhere.
A minor point: you'd have an unambiguous semantics for reading
rulesets, savegames and live commands: they take effect as soon
as you read them, overriding existing settings.

But for savegames expressing everything in this new language may
make them much larger, and that would be unacceptable.

> > They will definitely be needed if this language is to be extended to
> > be a client-side scripting language (a human readable, and more
> > powerful, version of the existing binary protocol) but that may
> > never arrive.
> 
> This is a completely different problem IMHO.

It is now, but it wouldn't be then.

> Some thoughts: you need
> also commands for normal packets like move-unit, build-city,...

They can be expressed in terms of primitive updates.  But I agree, this
doesn't seem very useful, unless you want to greatly extend the range of
possible actions (say, create a unit that moves a city, or that creates
a road between two cities all at once, or that splits in two).

> If you
> have a parser for this at the server you can also remove all packets
> and use such text-based packets.

Well, they would have to be in a binary representation for bandwidth
reasons.

> In the long run this allow more
> flexibility and easier extension. But this now a no-issue since we
> don't have a client side scripting.

Agreed, it's just a possible destination on the horizon.

>       Raimar

-- 
Reinier