Joan M Friedman wrote:
I've been lurking on this list, while I learn more about GRASS and gis
in general. It seems like it would be useful to have a web
application that can connect users with GRASS, and can connect with
other gis servers on the internet, and that it would be
reasonable to write such an app in java. (I write software in java, I
have friends who've been asking for this sort of thing, and it
seems like an interesting, if somewhat overwhelming, project.)
One piece of advice: a web interface will need to take great care to
validate all user-supplied input before passing it to GRASS.
Otherwise, the end result would be highly vulnerable to malicious use.
Currently, GRASS does just about everything which a publicly
accessible networking daemon shouldn't do (fixed-size buffers with no
bounds checking, use of system(), no input validation, etc).
Suppose I have GRASS on a linux box, and user1 starts it. Then user2
starts it. Are there two
entirely separate instances of GRASS running, or is there one GRASS
'server' with 2 clients logged into it?
A normal GRASS "session" basically involves setting some environment
variables then starting a shell (e.g. bash). There are no persistent
processes other than the shell (unless the user starts a "monitor" for
graphical output; this isn't required for commands which simply
manipulate data or export it to files, though).
The majority of GRASS commands are conventional Unix command-line
programs which perform a specific operation then exit. The commands
which are interactive probably wouldn't be useable via a web interface
(unless it has a built in terminal emulator).
If I ran GRASS on a web server, after writing code to allow people to
use it through the web,
would my web application have to start GRASS separately for every user?
There's nothing to start. The existing framework is really just a way
of setting up the environment for subsequent commands.
However, there are potential issues with concurrent execution. A
number of commands use "static" data stored within the "mapset", e.g.
the current region.
You would either have to have a pool of user ids (each with their own
mapset), or you would have to serialize operations so that no two
requests can operate concurrently.
Hopefully these kinds of problems will be eliminated in future
releases (e.g. they currently prevent a user from running multiple
sessions concurrently). However, they won't be fixed for the 5.0.0
release, which is currently the main priority.
--
Glynn Clements <glynn.clements@virgin.net>