[GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

On 02/02/17 09:22, Markus Metz wrote:
>
>
> On Wed, Feb 1, 2017 at 10:46 PM, Vaclav Petras <wenzeslaus at gmail.com
> <mailto:wenzeslaus at gmail.com>> wrote:
>>
>>
>> On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at club.worldonline.be>> wrote:
>>>
>>> I don't really agree with the idea that
>>>
>>> "Unfortunately, its [GRASS'] development is stagnating because of
> small interest
>>> from fresh and young developers. This is partially caused by the fact
> that its design and
>>> concepts are overcome by modern practices in a software development."
>>>
>>> I do not see GRASS stagnating. And even though GRASS uses an "old"
> language,
>>
>>
>> I think C is fine and that might be more clear now than in 2008, but
> C++ is popular too.
>
> 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.
>
>> 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.
>
> 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.
>
>> 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).
>
> 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.
>
> All-in-memory processing is so simple that any API would IMHO make
> things more complicated.
>
> The interface to the segment library is pretty simple: you need only
> Segment_open(), Segment_put(), Segment_get(), Segment_close().
>
> 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.
>
>>
>>> 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... :-)
>>
>>
>> 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.
>
> Note that the vast majority of portability and compatibility issues
> arises from Python and C++.
>
> Maybe this proposal addresses two different things that could be kept
> separated:
> 1) some higher-level C and C++ API

IIUC, a higher-level C API would be between the current API and modules. 
What functionality is needed at this intermediate level ?

Concerning the C++ API, I'm just a bit afraid that this will lead to 
more and more modules in C++ with the possible issues Markus mentions above.

Also, what exactly is meant by:

"Bridging of C++ RAII and try-catch with GRASS GIS C API exit and 
optional memory cleaning must be addressed."

This sounds like another attempt to create persistent state in GRASS (I 
guess its this discussion [1] coming back ?). Again, I have no problem 
with discussing the issue once again, but I don't think this should be 
done within a GSoC project without prior discussion and consensus on the 
dev-list.

Moritz


[1] https://lists.osgeo.org/pipermail/grass-dev/2014-April/068345.html