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

[Sören Gebbert]

Hi,

[snip]
> 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.

Agreed.

>
> 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.

Agreed.

IMHO, there is no need for a higher level C or C++ API. Addressing the
memory and exit behavior of GRASS
can be managed in Python using an RPC interface to PyGRASS or
C-wrapper functionality [1].

It would be meaningful to improve the high level GRASS Python
interface that makes implementing
GRASS modules much easier than coding modules in C or C++.
Making the current GRASS RPC interface ground solid, providing more features,
so that it can be used in stable, long-running GUI applications may be
a better GSoC goal.

[1] https://grass.osgeo.org/grass73/manuals/libpython/_modules/pygrass/rpc.html

Just my 2cent
MfG
Sören