<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">>please take a look at GAL project from 2008 [1]. Ma<br>
<br></span></blockquote><div><br></div><div>I didn't really work out the differences to GAL project but this GSoC project should be less ambitious, much more limited, cover smaller part of the functionality, and perhaps be less high level. Another difference would be that the GSoC proposal aims to cover both C and C++ APIs and is limited only to module development (no GUI-aware/friendly API).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't really agree with the idea that<br>
<br>
"Unfortunately, its [GRASS'] development is stagnating because of small interest<br>
from fresh and young developers. This is partially caused by the fact that its design and<br>
concepts are overcome by modern practices in a software development."<br>
<br>
I do not see GRASS stagnating. And even though GRASS uses an "old" language, </blockquote><div><div><br></div>I think C is fine and that might be more clear now 
than in 2008, but C++ is popular too. However, the motivation for GSoC is
 make writing of modules in C and C++ easier. We may discuss if 
"development is stagnating because of small interest" is true or not, 
but for sure we can have better interface which would attract more 
people. There are people writing custom C or C++ code for basic 
geospatial things which GRASS libraries do in a way which is better than
 what they have or aim for.<br><br>More pressing problem however are the
 modules which use variants of all-in-memory and tiling-on-disk raster 
reading modes. I'm not sure what is the state now, because MarkusM fixed
 a lot of those, but some addons were not included into core because of 
custom segment libraries (and even now they have custom all-in-memory 
implementations). <br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I imagine that it's unpleasant if all you believe in is OO, but that doesn't necessarily make OO the naturally best way to go... :-)<br></blockquote><div><br></div><div>Similarly to Python API, OOP is not the only thing we should focus on. C++ is a multiparadigm language and OOP is just part of it (e.g. templates are kind of big), plus there are different levels of doing OOP ("C with classes" versus more complicated OOP). So yes, the student should be familiar with more than just OOP.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
b) I'm afraid it's too big of a project for GSoC and that we would put the student in an uncomfortable position.</blockquote></div><br>It should be much smaller than GAL project and it should be mostly additions to API, not rewriting the libraries.<br><br></div><div class="gmail_extra">That's at least my idea. I hope this clarifies it a bit.<br><br></div><div class="gmail_extra">Vaclav<br></div></div>