[GRASS5] Platform for next generation UI

[Glynn Clements]

Russell Nelson wrote:

>  > Re-working the guts of each module for use in a library which is to be
>  > used by a long-lived application would be a lot of work, for several
>  > reasons:
>  > 
>  > 1. You need much greater robustness.
>  > 2. You need to make more effort to prevent memory leaks.
> 
> Urgh.  It sounds to me like you're saying that the GRASS is so poorly
> written that one function needs to be protected from another by the
> kernel's inter-process protection.

Well, that's the implication of 1, and in a sense it's true, although
your phrasing isn't entirely fair.

The problem is that reliability is subject to exponential decay. E.g. 
if the probability of a module crashing is 0.01, the probability of it
not crashing is 0.99 and the probability of running 100 commands in
succession with none of them crashing is 0.99^100 = 0.36.

IOW, if you want reasonable robustness for the application as a whole,
the robustness of each command needs to be very much higher,
essentially "bulletproof". The code in the GRASS modules wasn't
originally written to such constraints; it's reliability is merely
reasonable for its intended use.

Regarding point 2, if you're writing a standalone executable, not
bothering to free memory isn't a bug. There is no reason to do this
when the the kernel is going to do it for you.

>  > 3. You need to be able to re-initialise the state at each invocation. 
>  > Currently, the core GRASS libraries use a lot of static data. This
>  > data is initialised automatically at startup, and is discarded at
>  > termination. For a library, you would have to be able to explicitly
>  > re-initialise all of that data before invoking each command.
> 
> #1 and #2 are reasons to split functions between processes.
> #3 is a reason NOT to split functions between processes.

Huh?

> I would argue against you, but you're doing a perfectly fine job of it
> yourself.  In principle, you're not disagreeing with me.  You're just
> pointing out that an artifact of the implementation would make
> creation and use of a library difficult.

Exactly. But that's the whole point. We aren't discussing creating a
GIS from scratch, we're discussing where GRASS should go from where it
is now. If you were writing a GIS from scratch, you would do it very
differently to how GRASS has been written.

-- 
Glynn Clements <glynn at gclements.plus.com>