<div dir="ltr"><div><br><br>On Wed, Feb 1, 2017 at 10:46 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:<br>><br>><br>> On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>>><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,<br>><br>><br>> I think C is fine and that might be more clear now than in 2008, but C++ is popular too.<br><br></div>C++ is more problematic in terms of portability and robustness over time, have a look at the revision log of e.g. r.terraflow and the iostream library.<br><div><br>> 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.<br><br></div><div>Then the project should determine what is "better". This could be a project where a concept is going to be developed without writing a single line of code. The main objective would then be to first identify what is bad or too complicated and how to improve on it.<br></div><div><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><br></div><div>There are only a few modules requiring random access and external memory (e.g. but not only tiling on disk). IMHO, random access and usage of external memory are special cases, and I don't see how a higher-level API would help with these special cases.<br><br></div><div>All-in-memory processing is so simple that any API would IMHO make things more complicated.<br></div><div><br>The interface to the segment library is pretty simple: you need only Segment_open(), Segment_put(), Segment_get(), Segment_close().<br><br></div><div>Maybe it would help if there would a better description about the differences in the tiling-on-disk methods available in GRASS, i.e. the segment library, the read-only cache used by r.proj, and the rowio library.<br></div><div><br>><br>>> 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>><br>><br>> 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><br></div><div>Note that the vast majority of portability and compatibility issues arises from Python and C++.<br></div><div><br></div><div>Maybe this proposal addresses two different things that could be kept separated:<br>1) some higher-level C and C++ API<br>2) random read (and write) access to raster cells.<br></div><div><br></div><div>For both cases, a more detailed description of the objective would be helpful.<br></div><div><br></div><div>my2c<br><br></div><div>Markus M<br></div><div>>  <br>>><br>>><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.<br>><br>><br>> It should be much smaller than GAL project and it should be mostly additions to API, not rewriting the libraries.<br>><br>> That's at least my idea. I hope this clarifies it a bit.<br>><br>> Vaclav<br>><br>> _______________________________________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br><br></div></div>