I really like this idea and want to go further by splitting into four main parts:
- grass-lib: keep the current core libraries as is. Low level GIS layer - grass-plugins: implement raster/raster3d/vector/... whatever the current commands implement as libraries. These libraries spit out xml for building CLI/GUI interfaces. One plugin per module. High level modeling/analysis layer - grass-cli: very light xml parser. Maybe, we'll only need one command and give a plugin name and its parameters to this command. - grass-gui: also very light xml parser. This way, other GIS programs can use grass-lib and grass-plugins to build their interface from xml output without having to update their client code heavily whenever a major GRASS GIS is released. Regards, Huidae On Fri, Apr 18, 2014 at 5:15 AM, Pietro <[email protected]> wrote: > Hi Vaclav, > > actually I'm a bit more extremist... :-) > > I would like to split GRASS in three main parts: > - grass-lib > - grass-cli > - grass-gui > > often we have these things mixed to each other, for example a lot of > GRASS modules implement functions that could be moved to grass/lib > (e.g. r.stats). I would like to see the CLI interface just only as > command line interface to the GRASS library, not more not less. At the > moment each GRASS module implement it's own functions. > > The same is true for the GUI, inside the GUI libraries there are a lot > of functions and objects that partially implement functionality that > should be moved to lib. Again I would like a clearer distinction > between the logic/functionality and Graphic user interface. > > These changes could help to reduce redundancy and reduce the code size > of the GRASS project. > > Split the GRASS project in these three parts perhaps could help us to > clearly distinguish between functionalities and interfaces > (command/graphic),and we should re-organize the grass root > consistently. > > Splitting the library from the CLI, should make easier other FOSS > projects to use the GRASS processing capabilities. > > At least should be possible to build these parts separately, leaving > the decision to split in several packages to the package maintainer of > each distribution (Debian, Fedora, etc.). > > Regards > > Pietro > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
