[GRASS-dev] Who wants GUI and who does not and why

Glynn Clements glynn at gclements.plus.com
Sun May 4 00:40:54 PDT 2014


Huidae Cho wrote:

> I'm not talking about the current structure. Yes, the modules are the CLI
> right now and the GUI calls the CLI modules internally. What I'm saying is
> that it would great if we could separate the logic and CLI and put the
> logic in plugins

We already do that, except that the plugins are called "modules", and
the calling mechanism is program execution.

All of GRASS' significant functionality is in the modules. The
libraries are just utilities which ensure some degree of consistency
and avoid the need for modules to continually re-invent the wheel.

Splitting every single module into an "interface" executable and a
"logic" library amounts to a complete re-write of GRASS. Feel free to
start your own fork, but don't expect everyone else to jump on board.

There's also the fact that, with a persistent application, any
segfault takes down the entire application, any memory leak persists
for the lifetime of the application, etc. So you can't just separate
the code, you also have to clean it up significantly.

> Actually, even now, GRASS libs are called directly from GDAL for handling
> raster/vector maps.

That is long overdue for change.

It has been problematic ever since the r.external functionality was
added. Because now the GRASS libraries call GDAL, so the GDAL-GRASS
bridge has to be a separate plugin to avoid a circular dependency.

And if we ever removed the support for the legacy versions of the
raster format from GRASS, GDAL would automatically stop supporting
them as well.

Now that we have r.external, the ideal solution would be to move the
actual raster I/O code into GDAL itself, and perform all raster access
via GDAL.

I would have done it myself, except that it ideally needs to be done
by two people to avoid "contaminating" GDAL with the GPL used by
GRASS. One person would document the raster file formats, while
another would write a clean implementation based upon the
documentation.

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


More information about the grass-dev mailing list