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

[strobe anarkhos]

At 9:48 PM -0800 3/21/01, Eric G. Miller wrote:
>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 don't see why X11 would help. X11 has no concept of layers or resolution independent graphics. Lines drawn in X11 are in integer pixel coordinates unlike say display postscript or Apple's Quartz display server which can draw lines in floating coordinates (and anti-alias such lines so you can see the sub-pixel changes). 

I doubt X11 would have changed the evolution of GRASS graphics much.

>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.

That's basically what I'm doing. You can take a look at the GRASStep project which has the eventual goal of implementing such features (and more).

>
>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).

It would not make such things harder to implement.

>
> > > > 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 suggest writing a model for GRASS data using CoreFoundation which allows objects to be created and accessed in C. Once this is done we rewrite command line programs to act as controller objects. Thus we preserve the model and thus we can more easily implement persistence, multiple undo/redo, high level scripting, etc. Using the model-view-controller OO methodology the model and view objects become highly reusable and we also have a clear path of execution. 

As GRASS is now one hand doesn't know what the other is doing.

We could also use the OpenStep Foundation API if we wish, I suggested CoreFoundation because some programmers here may not want to bother learning ObjC (which is rather easy actually).

>
>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.

Check out GRASStep.

The model I'm using for GRASStep only deals with my private canvas model so graphics are persistent and support undo/redo and high level scripting. However we can use this as a starting point to author a model for the GRASS library so we have one coherent system.

There are several ways to implement this. One is to leave the GRASS library alone and have our library call it, however if anything else calls the GRASS library directly you break the model (for example undo wouldn't work, or worse have bad consequences). Thus I think the best solution would be to reorganize the GRASS library as a coherent framework which we can write plugins for. CoreFoundation provides a mechanism to do just this! Everything would be a plugin including the graphical application (if one is used). 


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