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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev