<div dir="ltr">I really like this idea and want to go further by splitting into four main parts:<div><br></div><div>- grass-lib: keep the current core libraries as is. Low level GIS layer</div><div><br></div><div>- 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<br>
</div><div><br></div><div>- grass-cli: very light xml parser. Maybe, we'll only need one command and give a plugin name and its parameters to this command.</div><div><br></div><div>- grass-gui: also very light xml parser.</div>
<div><br></div><div>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.<br></div>
<div><br></div><div>Regards,</div><div>Huidae<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 5:15 AM, Pietro <span dir="ltr"><<a href="mailto:peter.zamb@gmail.com" target="_blank">peter.zamb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vaclav,<br>
<br>
actually I'm a bit more extremist... :-)<br>
<br>
I would like to split GRASS in three main parts:<br>
- grass-lib<br>
- grass-cli<br>
- grass-gui<br>
<br>
often we have these things mixed to each other, for example a lot of<br>
GRASS modules implement functions that could be moved to grass/lib<br>
(e.g. r.stats). I would like to see the CLI interface just only as<br>
command line interface to the GRASS library, not more not less. At the<br>
moment each GRASS module implement it's own functions.<br>
<br>
The same is true for the GUI, inside the GUI libraries there are a lot<br>
of functions and objects that partially implement functionality that<br>
should be moved to lib. Again I would like a clearer distinction<br>
between the logic/functionality and Graphic user interface.<br>
<br>
These changes could help to reduce redundancy and reduce the code size<br>
of the GRASS project.<br>
<br>
Split the GRASS project in these three parts perhaps could help us to<br>
clearly distinguish between functionalities and interfaces<br>
(command/graphic),and we should re-organize the grass root<br>
consistently.<br>
<br>
Splitting the library from the CLI, should make easier other FOSS<br>
projects to use the GRASS processing capabilities.<br>
<br>
At least should be possible to build these parts separately, leaving<br>
the decision to split in several packages to the package maintainer of<br>
each distribution (Debian, Fedora, etc.).<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Pietro<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br></div>