Re: [Swarm-Modelling] Something Glen said

[Marcus G. Daniels]

I wrote:
> A first step would be to separate the packaging of GUI and non-GUI 
> Swarm.  Scott did some of this internally for GNUstep, it just needs 
> to be broken into physically separate code bases. Another step would 
> be to rehost Swarm on the Apple Objective C system.    That would drop 
> two libraries from Swarm as dependencies and some very nasty technical 
> issues (that would be handed off to Apple, at least in part).  This 
> means careful coordination with the Apple Objective C people to get 
> hooks for the features Swarm needs (for phases). 
Glen wrote:
> That's the wrong approach.  I think it would be much more appropriate to
> use the existing Apple system.  If that means changing Swarm, then so be
> it.  The defobj API could be implemented without requiring the peculiar
> run-time.  Granted, Swarm wouldn't meet the initial Swarm requirement of
> automatically determining more efficient implementations of particular
> classes.  So, it would mean a bit less computational efficiency.  But, I
> don't think the SDG should hook its development timeline to Apple or GNU
> projects if it doesn't have to.
>   
And less religiously, as phase switching finds its way all the way into 
the Java layer with phase-specific interfaces, it would be disruptive to 
users to take it out. 

The task is simply to realize a more portable phase implementation using 
the Apple runtime.   Not a problem on the SDG's budget if it chooses to 
fund this.  On a longer project timescale it can could make sense to 
wait for Apple or GNU, but here the SDG would just do it.

> > B) a core library for representing object lifetimes and dynamic messages in a 
> > language independent way. Thus A)
> > is really not that hard to do because the basic RPC approach is in
> > place, and because Swarm can already generatesIDL for itself that 
> > could be handed of to a COM stubber (e.g. Firefox's cross platform
> > COM or the Sony/IBM stubber for the PS3).
> >     
>
> This sounds like a barrier to ABM modelers to me.  The SDG is not likely
> to garner the resources (money or programmers) to do this correctly and
> completely.  Therefore it shouldn't be done by the SDG.  In fact, all of
> these barriers should be removed in favor of a simpler set of features
> that is accessible to modelers.
>   
B) just amounts to making defobj a standalone library.   It's the defobj 
you know about with infrastructure that doesn't need to be exposed to 
users except to the extent it makes different systems talk to one 
another transparently.  
> > C) a discrete event simulator module that has a collections library
> > with it.  The collections library is needed for the scheduler and for
> > legacy simulations. D) simtools and analysis, possibly merged but
> > stripped of any direct reference
> >     
>
> Excellent.  However, again, the libraries need to be complete. 
>   
The libraries need to do what the interfaces say they will do, which the 
unit tests then ensure.   Everything else is a matter of definition, 
which the SDG can revisit this per user requests.   More documentation 
work would surely help clarify the declaration to the user. 

What isn't complete in the discrete event simulator is parallelism, but 
there is little practical motive to do that unless there is a 
low-latency way to make asynchronous calls (like on an affordable 
tightly integrated multiprocessor system like the Playstatio n 3), 
because you'd never amortize the cost of these calls unless you were 
using MPI and Infiniband, or the step methods happened to be somewhat 
compute intensive.

> If the SDG doesn't have the resources to complete them, then we should opt for
> an existing library like Foundation in Apple/GNUStep.
That's fine for a collection library, but won't help for the multilevel 
discrete event simulator.

> > A web-based monitoring application could
> > equally well setup up simulations in the browser itself (e.g. with
> > JavaScript agents), or it could initialize native objects on a
> > Playstation 3 or clusters or supercomputers (either real or byte code
> > streamed to it's processors or precompiled classes advertised as a
> > standard web service on those machines). 
> >     
>
> Again, the features you're describing sound like barriers rather than
> facilitators.  _If_ these were done well and completely, then they would
> be very helpful.  But, the likelihood is that they will not be done well
> or completely. 
>   

We can't have a blue sky discussion without you suspending prejudices 
about feasibility.

As it happens, it is feasible.   Swarm already has run with JavaScript 
agents in Mozilla.   Swarm already has an IDL generation system usable 
by the Cell process toolchain.   The likely way such things may occur is 
if the SDG funds the rather miserable but affordable part of the work 
(release making and integration), and the fun stuff is left to volunteers. 

> So, it would be more strategic to integrate with other
> data structure libraries for spatial computation.
Yes, of course.  PostGIS (GIS on Postgres), and COM integration to 
ArcView are a couple of options.