5.1 architecture (was Re: [GRASS5] sockets question)

Eric G. Miller egm2 at jps.net
Thu Mar 22 00:48:20 EST 2001


On Wed, Mar 21, 2001 at 07:23:13PM +1100, John Reid wrote:
> > Yes, the architechture of the whole system is wrong...
> 
> Care to elaborate?  Do we have a better proposal?  Or even just some rough ideas?

Well, please understand my criticisms of GRASS are in good faith; I'm
just a little frustrated with some elements of it.  Also, understand I'm
a rank amateur when it comes to GUI stuff (generally it doesn't interest
me much).  But here are some of my observations:

The architechture for GRASS display was designed some 10+ years ago
(??).  Several decisions were made to focus on portability over
functionality (probably a good thing).  Among those decisions was to set
up the display drivers as basically dumb pictures in which to paint
pixels.  A small amount of functionality was incorporated for getting
mouse input.  The design forced most of the hard work into the raster
library and display modules (since it offers only a very primitive API).
Unfortunately, it forces the display modules and raster library to be
too intimate with the specifics of the display screen (screen coordinate
translations is a good example).  Also, there's very little "state"
information that the display code can utilize (practically none).
Anyway, much of this design seems to have been done well before X became
a standard for *nix and hence drivers had to deal with the vagaries of
entire graphics subsystems -- so, a limited command set made driver
author's job easier.

I really don't have a coherent picture in my mind of what a new system
would/should look like.  Basically, I think the display driver should
know how to draw map elements directly (i.e. they should be built in).
It should know about the current coordinate system (as well as its
screen coordinate system) and be able to make the necessary translations
on the fly.  It should know what map layers it is currently displaying,
and be able to dispatch the appropriate handler whenever a
resize/redraw/query event occurs.  Basically, the system needs to be
designed to be responsive to the user.

I realize eliminating the display module <=> display driver separation
would make things like the CELL or HTMLMAP driver harder to implement.
As far as something like CELL, I think it could be better replaced by
an improved map scripting => output system.  I'm tending to think
HTMLMAP functionality could be accomplished fairly easily with a vector
command and arguments giving image size (for scaling).

> > > If I could I would start over using the GRASS library as the starting
> > > point creating a framework for model, view, and control commands but
> > > I'm only one person and I have to work within my limits. As such I can
> > > work with the current flawed framework (time permitting).
> >
> > Pretty much have to start from scratch I think...
> 
> Or could we rebuild the core libraries and define new API's (for 5.1? though
> probably slightly longer term), then provide wrappers around the new code so
> existing commands don't break?  Should be possible for at least part of the
> library, such as the catalogue services and region of interest - though as a
> newbie to grass I could well be wrong about that ;-)

There's too much of this wrappers around old code stuff already.  It
tends to compound on itself making the system less flexible and less
maintainable over time.  Sometimes it's better to break stuff.  Of
course, we should have a firm idea of what the plan is...  

I hope I've made some sense and I hope to see more discussion (and
hopefully code) come out of this.  In general, I'd like to see some more
reevaluation of the system architechture as a whole.  There are several
areas that I think could be much improved if we did some brainstorming
on how elements of the architechture could be better.  Right now,
there's a feeling we just need to get something out the door (I tend to
agree with this sentiment...).  But I think it's worth developing a
longer term road map about how we want to see GRASS evolve.

Ciao,
-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list