Re: ABM/Toolkit futures [was: Swarm futures (was Re: GNUstep and MacOS X Port Effort)]

[Gary Polhill]

Whilst I agree with Jason that Swarm should be easier to get up and running 
with, one of Swarm's main advantages as far as I am concerned is its 
flexibility. Personally, I think making it easier to use without sacrificing 
that flexibility is going to be a real challenge. One solution (and I haven't 
read enough of the discussion to check if I'm repeating something someone else 
has said -- apologies if so) would be to build more on top of the existing 
libraries in terms of standard apps, classes of agent, modelSwarm and 
observerSwarm.

The current Swarm Apps are all very well, but they aren't overly configurable. 
Is there some way of writing an app that could be configured to function more 
flexibly? For example, could we have a modelSwarm that could build a schedule 
based on a script written in a SwarmScript (or whatever) file that got loaded 
in at run-time. Similarly, how about SwarmAgents and SwarmCells that get their 
behaviour from script files? The modelSwarm would basically act as an 
interpreter in the -buildObjects/Actions methods, and similarly the SwarmAgents 
and SwarmCells in their -step methods. There must be quite a broad class of 
simple-ish apps (such as spatial PD) that could then be written (and exchanged) 
knowing only the scripting language. (The approach would be a little different 
from that of MAML, as it wouldn't require any compilation.)

For people who wanted to get further in to Swarm, and were prepared to learn 
Obj-C or Java, they could start by subclassing from a library of standard 
Agents, Cells and modelSwarms. Hopefully all they'd have to implement in their 
subclasses would be some kind of -step method in the agent/cell and 
-buildObjects/Actions in the modelSwarm.

People who wanted to get deeper still could then still write their Swarm-apps 
much as they do now.

I guess I am wondering how much of most people's wishes could be achieved 
through adding a bit of flesh on the Swarm libraries' bones, rather than 
rebuilding the bones themselves.

Gary

Gary Polhill
Research Scientist
The Macaulay Institute
Craigiebuckler
Aberdeen AB15 8QH
UK
Tel: +(44) (0)1224 498200 Ext 2238
Fax: +(44) (0)1224 311556
e-mail: address@hidden
http://www.macaulay.ac.uk/
http://www.macaulay.ac.uk/fearlus/

>>> Jason Alexander <address@hidden> 05/10/02 12:50:19 >>>

...

If you believe what I've said above, the biggest problems are:

(1) Make Swarm easy to install.
(2) Make Swarm easy to use (without, presumably, sacrificing power 
and/or features)
(3) Make it possible to describe modeling problems in a high-level 
language.
(4) Make it easy to share models.
(5) Make it easy to graft custom GUI interfaces on top of Swarm.
(6) Make it easy to create (and share) extension libraries for Swarm.

Other desiderata:

(7) Get Swarm running (easily) on all major platforms.
(8) Make it possible (perhaps) to embed Swarm models in a web page.

...


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.