> 1) What open source language do we use?
Something that everyone who wants to use the package is familiar with.
Maybe as Gene said, we make a bunch of components. How about Corba
components? Then someone can serve them, and everyone can access them.
Only problem is, that this requires somebody to cough up a server to do the
dirty work; I am assuming that often the computation will be kind of large.
Something entirely client side would put the load back on the user, which is
probably fairer, but not efficient.
How about a P2P solution? Everyone who wants to use this thing also makes
themselves available to process work for others?
So you'd get an architecture where you download a bunch of components from a
central server, install them locally, as well as a P2P program which handles
communication between client code and servers (yourself included) for
processing.
User environment of choice
|
Local Wrapper (eg: COM interface for Windows users)
|
P2P front end (manages farming out requests)
||| (communication between local or remote front/back ends)
P2P back end (receives incoming requests and reports results)
|
Raw Processing Components
Urgghh... spreadsheet is starting to sound good again
> 2) How is this software package to be accessed?
With server hosted components, you could use Corba to access them.
With that P2P architecture, you get an appropriate local interface for any
tools that you want to use. As long as someone codes it up :-)
> 3) What architecture?
See horribly complex architecture above
> 4) Are there existing open source components that
> we could incorporate?
...
> 5) Are we looking a simulation of some sort?
???
> 6) What kind of user interface? Graphic? etc.
Anything with nice clicky buttons and spinning icons :-)
Emlyn
(where's my sig gone?)
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:59:41 MDT