Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability a
Home

[Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability a

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Development Strategies [Was Documentation, Usability and Development]
From: Gregor Zeitlinger <zeitling@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 4 Dec 2001 23:15:11 +0100 (CET)
Reply-to: gregor@xxxxxxxxxxxxx

On Mon, 3 Dec 2001, Andrew Sutton wrote:
> > 1) XML embeddable although I think all are if you use CDATA includes
> > 2) access to XML values (simkin has already done that, but others could
> > access those after they're parsed with DOM or JDOM or whatever)

> i'm still not entirely certain we need scripting. i think the requirement 
> would be that a scripting engine would have to instantiate objects in such a 
> way that the kernel could deal with them without having to call back to the 
> scripting language.
Yes.

> for example, if i script a module to register a bombard capability, that 
> should be the end of it. the scripting language should create the object or 
> whatever data needs to be created and register it. the kernel should never 
> call back to the scripting language during game play. this would be a sort of 
> fire and forget type language. the problem is, i'm not sure if scripting 
> languages can do this... 
I think Jython can do this.

> i think the closest we can get is a configuration 
> language for runtime attribution of game rules and possibly a buildtime 
> descriptor language for building module code that can be built separately. 
> i'm probably going to end up being wrong :)
I wanna find out how other projects do it. Do you know?

> lets get rid of requirements 1 and 2 for right now as those specify a 
> particular implementation.
Ack.

> actually, lets talk about a formalization of modules. we could define the 
> formal, approved modules to be in c++/java (whichever we choose for 
> language), but allow the configuration language to do inline scripting of new 
> extensions.
sounds like a good compromise.

-- 
Gregor Zeitlinger      
gregor@xxxxxxxxxxxxx



[Prev in Thread] Current Thread [Next in Thread]