lib: add grass JSON API

[NishantBansal2003]

Pull Request Description

Ref #4697

Purpose:

This PR addresses #4697 by adding the gparson wrapper for better JSON handling in GRASS GIS.

Changes:

• Added thin wrapper of the parson with a unique GRASS API.
• Added unit tests to cover all major operations.

[nilason]

Sorry for being slow on response!

What you have come up with looks promising. But before we go into detail, there is structural change I'd prefer we should pursue. As this now stands, we will end up with two json libraries: parson.so and gparson.so. It would be better to end up having only one, the latter. Do you think of a possible solution to this, without changing code that now links to parson.so? Phasing out the direct use of parson API may then be made module by module.

[NishantBansal2003]

To ensure we only have one JSON library (gparson) while maintaining backward compatibility, the possible solutions from my understanding are:

• We’ll keep parson internal to gparson, ensuring it is only used by gparson. Other modules will interact with gparson directly, preventing any direct access to parson from other modules. This can be achieved by making parson a static library, accessible only via gparson.
• Initially, we’ll retain the parson API for compatibility, but over time, the goal is to make sure that parson is only used by gparson, and all other modules rely on gparson directly.

This solution is based on my current understanding, and there may be better approaches. I welcome any input or guidance from other contributors on this.

[nilason]

A possible way may be to (1) include/add the "gparson" API on top/together with current parson; (2) convert current user code to use gparson API; and (3) drop/rename current parson library to gparson (original parson API will unavoidably be accessible, but not encouraged–not part of GRASS API–a situation we will end up with in any case).

Perhaps gjson would be a better name for GRASS json API library, thoughts anyone? Anonymising the backbone library, for future eventual freedom to change.

[NishantBansal2003]

I made some modifications and also added tests. Please take a look.
cc: @nilason

[nilason]

I like the direction this is going (and I tested with an updated version of #4665, which passed on Mac and Win runner). Before moving forward–and to avoid doing changes back-and-forth–let us hear out the opinion of other dev team mates. In particular on the question of unit tests in library: should they be in-compilation tests (like lib/vector/diglib or lib/cdhc) or post-compilation tests (like lib/raster3d)?

[NishantBansal2003]

I like the direction this is going (and I tested with an updated version of #4665, which passed on Mac and Win runner). Before moving forward–and to avoid doing changes back-and-forth–let us hear out the opinion of other dev team mates. In particular on the question of unit tests in library: should they be in-compilation tests (like lib/vector/diglib or lib/cdhc) or post-compilation tests (like lib/raster3d)?

Can you provide some opinions here...
cc: @echoix @cwhite911 @petrasovaa @wenzeslaus

[NishantBansal2003]

I like the direction this is going (and I tested with an updated version of #4665, which passed on Mac and Win runner). Before moving forward–and to avoid doing changes back-and-forth–let us hear out the opinion of other dev team mates. In particular on the question of unit tests in library: should they be in-compilation tests (like lib/vector/diglib or lib/cdhc) or post-compilation tests (like lib/raster3d)?

Can you provide some opinions here... cc: @echoix @cwhite911 @petrasovaa @wenzeslaus

Hi all, just following up to check if there are any thoughts or preferences regarding this. Let me know if there’s anything I should adjust or address before proceeding. Thanks! 🙌

[echoix]

I don't know a lot about in-compilation tests. Usually projects like to have them as a separate step, as this testing time at compilation is not always relevant once distributed.

You might have less help with in-compilation tests, or the persons that know about it here are less frequent or have contributed longer ago.

For in-compilation tests, you would need to be careful in order to make sure that all dependencies are already compiled (by dependencies I mean makefile targets). But also, we are working towards using CMake, albeit slowly, but it will have to be ported their too when we will get at it.

Since I know more about what you call post-compilation tests, obviously it would be my choice. But if you have something that justifies one or the other, knowing the possible drawbacks mentionned, the best solution could be one or the other ;)