[GRASS5] some thoughts

[Bjorn Roald]

Hi all,

I have been following this news group silently for some time, but now you
have finally got me writing.

My interest in GRASS have primarily been experimental.  In general, I am
interested in free tools for geospatial computing.  Currently I work as a
programmer and system designer in a large scale software project.  I have
some user experience with generic GIS tools (mostly MapInfo some years
back).  As a software user, most of my related experience have been using
applications centred around dynamic geospatial data, and presentation of
this type of data as an overlay on more static "map" data.

Well, back to the discussion,

I think both Roger and Glynn have some valuable opinions, I don't think they
are excluding each other in any way.

My experience with GRASS as a user tool concur with Roger's.  The command
line tools are a blessing as far as giving flexibility, but a curse as far
as user friendliness for the less experienced user (like myself).  Roger
wants some tools automating some of the small quirks the experienced user
does without even thinking of it...  well I have also struggled with the
monitors in GRASS. Coming from the outside, with no GRASS experienced friend
to teach me, I find the hole concept rather odd. The fact that they don't
work right away - does not help.. I am afraid this discourages a lot of
potential GRASS users, even the ones that rather starts with the command
line interface than attempting the tcl/tk stuff.

Glynn is bringing up something that need to be addressed if GRASS is ever
are going to get a modern UI.  The cost of a modern UI is almost guarantied
to be less flexibility than the UNIX like command line tools used today.  I
don't think the community should even think of breaking what you have, to
get what you want.  And that is why a more layered architecture of the
libraries and/or tools should be considered.  I think the main thing a
modern UI can do for GRASS is to increase the user base, and therefore also
the incentive and award for being a GRASS developer.


Some thought from me:

layer 1:
basic current and future GRASS and other libraries

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.

layer 3:
executable command line tools, as today - but more rigid and less
interactive.  Intended as a better option for software generated or managed
scripting.  Calls level 2 equalents after setting up streams.

layer 4.
existing command line UI.  Calls level 3 or 2.

layer 5.
Current an future GRASS supported GUIs.  Calls level 2, 3 or 4.

layer 6.
not a GRASS supported level, but a category for other applications bases
on the lover layers in GRASS


Just in case someone feels like jumping on this, that is Ok - go ahead. I
don't write this based on knowledge of the current state of the source code,
I have been to busy to have time to dig into it.  Neither do I promise to do
that on the future.


-- Bjorn Roald