Regarding parallelism, in the most general case (of a spatio-temporal
EVENT modeler) I think the answer is "it depends". It depends on how
connected your graph is. In the case of STEM today and the way we have
implemented air travel, the application should be able to make great use
of parallelism. The world naturally can be divided (for example) by
contents with relatively few edges than need to be communicated between
servers. This lowers the messaging overhead and simplifies partitioning
and distribution of the problem.
Regarding the google maps interface idea, this is a good suggestion. We
don't need to render the internal polygons in STEM but we do need an
association between IDs and locations on the graph. It's fairly easy for
us to plug in other viewers. I think the more difficult part of running on
the server is giving users an intuitive interface with the functionality
they need to "compose" a problem the way they currently do with the STEM
Eclipse rich client app.
One idea, maybe we can divide STEM so users can download the designer
perspective and run that locally. Once they have created their own
scenario we could send the scenario (and xml file) to the instance of STEM
running on the server. Since we now have full import/export functionality
working, users can already email and share their own custom scenarios
(graphs and diseases they have created). If the simulation perspective
could run on the server we can simply send it the scenario to run through
a web interface. I agree the preferred visualization might change over
time. If we can make a single instance of STEM work server side we could
then thing about how to add the parallelism...