[GRASS5] some thoughts

[Glynn Clements]

Eric G. Miller wrote:

> > Some thought from me:
> > 
> > layer 1:
> > basic current and future GRASS and other libraries
> 
> In order for GRASS "libraries" to be even usable as shared object libraries
> will probably take considerable rewriting.  They rely heavily on a lot of
> global data.  Not to mention, their contents probably need a reorganization.

A simple ".a" -> ".so" conversion is simple enough; Linux-style shared
objects don't have the same sort of restrictions as e.g. Windows DLLs.

> > layer 2:
> > user level libraries e.g. equalent to functionality of command line tools,
> > e.g. v.in.mif would use a layer 2 routine called v_in_mif(...) which works
> > on generic streams set up by the caller to files, pipes, sockets, or memory.
> > Basically, the idea is to move most of the work-horse code into these
> > library routines and publish them as a library with a documented and
> > supported interface.  UI developers may use layer 2 routines directly.
> > Additional layer 2 routines should also support multiple concurrent
> > environments.
> 
> I essentially agree with this scenario.  My thought are, this part would
> basically be broken into two or three related sets of things.
> 
>   1.  You have a function entry point that does the task.
>   2.  You have a set of "generic" input validation routines.
>   3.  You have an interface specification, such that command line, GUI,
>       whatever, can be generated.
> 
> Such a scenario wouldn't necessarily work with all types of commands, but
> I think it'd work for most.  It gets more complex with functionality that
> needs to interact with the user more (and modifies its behavior based
> on inputs).  Such functionality would probably have to be written specific
> for the interface type (at least partially).

Also, I'd just like to make clear my preferred approach regarding a
user interfaces (graphical or otherwise).

I'm definitely *not* aiming for a monolithic program, but something
more akin to tcltkgrass, where "commands" (e.g. menu entries) would
spawn separate executables.

The main advantage of this approach is the robustness provided by
"insulating" the commands within separate processes. If a specific
command segfaults, exhausts memory, calls exit() etc, it doesn't take
down the entire session. Also, system resources (memory, file
descriptors, etc) are guaranteed to be freed.

This means that we don't have to get rid of every single crash bug,
memory leak, and exit() call before the resulting system becomes
usable.

What I am aiming for is to make the individual commands more "program
friendly" (c/f "user friendly"). This includes things like:

+ Not trying conduct question/answer sessions with the user on
stdin/stdout.

+ Not using modal loops with e.g. R_get_location_with_*.

+ Overall consistency regarding argument parsing (including --help and
--interface-description), error/warning handling etc.

+ Self-description (again including --help and --int-desc), e.g. with
more precise argument type information (i.e. more types than just
string/int/float, e.g. "existing raster layer name" rather than just
"string"), allowable argument combinations (e.g. option groups) etc.

+ Overall separation of functionality from interface. E.g. programs
like d.what.* might have coordinates passed as arguments or fed on
stdin, leaving it for the UI to obtain the coordinates from the user.

This would allow for a more integrated UI than is currently possible.

E.g. tcltkgrass prompts for arguments using fairly generic dialogs,
then runs the command and ... well, the command does whatever it does;
it's effectively detached from the UI at that point.

The command may obtain further input from the xterm in which it is run
(either in teletype-style prompt/answer form, or using Vask, or a
free-form curses interface) and/or from the monitor (either just
coordinates or "menu" selections in the style of d.menu).

Ultimately you can only get so much integration before separate
processes start to become a problem. But eliminating the exit() calls,
opportunities for fatal errors[1] and memory leaks isn't going to
happen overnight.

[1] By which I basically mean crashes. G_fatal_error() can be modified
to allow a "fatal" error handler to be installed which could call
setjmp() rather than exit(). This would allow "exception" style error
handling rather than having to pass NULL/-1/whatever all the way up
the call stack.

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