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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev