Re: [Repast-developer] RePast and extensibity

[Kelly P. <kel...@ya...>]

The issue is important and because of its potential impact people should take the time to think and express their opinions. Although a newcomer to RePast here is mine.
 
Separating appearance from behavior may be a first step towards defining a "plugability" layer. 
G1. I would personally like to see the objects/agents "registering" with a display server (this would for example allow to zoom on a certain region of the space).
G2. A flexible way of mapping agent features onto graphics objects (this may include mapping a cellular 2 or 3D space onto a different representation space) that are visible on the interface layer
G3. Implement (for a starter) point 1 and 2 of Mark's Repast <--> Platform X interface
 
The same method may be applied to creating a data collection interface. The "observability" layer.
O1. On the one hand various objects/agents can "register" with supplying certain information into the "observability" interface
O2. On the other hand the user may plug in methods of processing (of data) into the "O" layer
O3. Plug the output of O2 into a data collection graphical representation G1-G2 to end up with a (graphical) representation of the collected data.
 
Kelly

"Mark R. Diggory" <mdi...@la...> wrote:
I'm curious what others think about RePast in relation providing support 
for features such as Java3D and Geotools. I think we start to really 
reach an unrealistic limit in terms of packaging all this functionality 
directly into RePast as one monlithic project. It also becomes 
questionable as to whether RePast gets added to GeoTools (or any other 
Platform) or the other way around during this extension process.

Maybe it would be wise to begin a goal of defining a "plugability" layer 
for RePast such that the "core" features of RePast can be isolated from 
the "extensions". This way one can either use the "bare-bones" of 
RePast in thier project without having to drag along all the features 
they may not actually be interested in, or they can provide an extension 
to RePast itself if it is acting as the framework.

Mostly, these extensions tend to be isolated in the area of rendering. 
But they do also involve mapping between various datastructures in both 
RePAst and the Framework of question. It would be logical to consider in 
the future that plugging RePAst into "X" platform will involve providing 
"Graphical" and "Nongraphical" bindings to and from that framework.


RePast Platform X


1.) Implementatation of RePast space, graph or topology interfaces in 
external API's for execution from within RePast.

RePast Interfaces <-- Platform X Data Structures

2.) Mapping model data structures to an external rendering engine.

RePast Model Data Structures --> Platform X Rendering Engine

3.) Exposing model controls and properties to external platform.

RePast Model Properties/Controls <-- Platform X

As we are starting to do to more of this "extension" these days. It 
would be wise to begin such discussions while the interest is there. 
This can happen at a couple of levels both internally to RePast with its 
own displays/controls and external to RePast in relation to GeoTools and 
other platforms that we are interested in "interfacing" with RePast.

-Mark




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Repast-developer mailing list
Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software