[GRASS5] some thoughts

[Glynn Clements]

Roger Miller wrote:

> > In order to be able to implement a proper GUI (as well as things like
> > a web interface), the core programs have to cease using G_ask_*,
> > R_get_location_with_*, stdin, stdout, stderr, etc. Instead, they need
> > to just parse the command line, read data, perform computation, write
> > data, and exit.
> 
> I wasn't grumbling about the user interface, much less about the GUI.  I
> use the command line interface, because GUI's don't work well over a slow
> network link and I often work from home over a 56K modem. Removing the
> terminal interface from the commands would destroy much of the value in
> GRASS.  On the other hand, you could rewrite the parser to eliminate some
> the interactive prompts and it wouldn't bother me at all.

The main problem with the terminal interface (by which I mean Vask,
G_ask_* etc) is that it gets in the way of any other kind of usage. 
E.g. tcltkgrass has to run every command in an xterm because the
command might depend upon a terminal.

The other big problem is the "session" mechanism, and the way in which
it interacts with mapsets. This means that:

1. Concurrent sessions on a mapset aren't possible, because the
current region is stored in the mapset.

2. Concurrent sessions for a user aren't possible, because some of the
information is stored in $GISRC.

Now, some form of persistent state is certainly useful; I wouldn't
want to have to type:

	d.something gisdbase=... location=... mapset=... region=... monitor=...

for every command. OTOH, this might be preferable for a web interface,
rather than having to generate mapsets on the fly. It wouldn't be that
hard to modify G_parser to automatically add such options to every
command (in the same way the Xt programs all accept "-display", "-xrm"
etc), *except* that a few programs use these settings to initialise
the defaults before calling G_parser().

In principle, it shouldn't be hard to combine $LOCATION/WIND and parts
of $GISRC into a dedicated state file, which would be generated at
session startup based upon $GISRC (which would then be just a user
configuration file, like every other ~/.*rc file).

There would probably have to be some locking added to the
applications. I doubt that it would be sufficient to add locking to
libgis alone, as you would need to ensure atomic operation of
read-modify-write cycles and multi-file updates (e.g. cell, cellhd,
cats).

Also, the $GISDBASE/$LOCATION_NAME/$MAPSET directory layout doesn't
coexist particularly well with Unix file permissions. E.g. $GISDBASE
has to be writable for users to be able to create locations, and each
location has to be writable for users to be able to create mapsets. A
"mapset path" would be better, e.g.

	GISPATH=/opt/grass-data:$HOME/grass-data

with locations existing beneath each component.

> My suggestion was that a layer (running as a user-space daemon) should be
> inserted in the libraries.  That layer would be responsible for managing
> the user's run-time environment and coordinating between different tasks.  
> The user would no longer need to micro-manage his own environment, and
> some variables (location, for instance) could be changed on the fly. Other
> variables (like the region settings) could be altered by one user without
> effecting other users, making simultaneous access a more realistic
> possibility.
> 
> I think the new layer could be built into the exiting GRASS architecture
> without breaking any of the existing functionality.  The initial version
> would be simple and have a minimal role. Additional library routines could
> be rewritten to use the added layer as time goes by.

I'm not sure how a separate daemon would help. I think that most of
the problems stem from the way in which the settings are stored in
$GISRC and $LOCATION/WIND (and others; e.g. $LOCATION/GROUP, which
also conflicts with the $LOCATION/group directory if your filesystem
isn't case-sensitive, e.g. Cygwin, and maybe MacOS).

Also, regarding the monitor, I'm becoming more convinced that the
redraw-on-resize feature was a mistake. Whereas the monitor used to be
a standalone component, living at the bottom of the call graph, it's
now part of a loop which binds it to the session in which it was
started. It would have been better to extend the protocol to support a
d.resize command, which would basically run d.save, resize the
monitor, then redraw the contents using the d.save output.

Actually, I'm wondering whether it would be better for D_add_to_list
et al to store the data in a file instead of within the monitor. In
any case, a graphics terminal and a bunch of d.* commands aren't
really a substitute for a stateful viewer.

The thrust of my position is that much of what exists to support
interactive use doesn't do a particularly good job of it and, more
importantly, it's getting in the way of something more substantial.

-- 
Glynn Clements <glynn.clements at virgin.net>