[Feat] New GRASS json API

[nilason]

Is your feature request related to a problem? Please describe.

Presently, the json parser library Parson singlehandedly is used to generate libgrass_parson.[so/dylib], making its API directly a part of GRASS public API.

Recent work on #4665, have revealed compatibility issues with this approach. GDAL has embedded JSON-C code, which API in part overlaps that of Parson's, causing conflicts upon linking the libgrass_parson and GDAL at the same time.

Describe the solution you'd like

In order to overcome this conflict, we could create a thin wrapper of the json parser (in this case Parson) with a unique GRASS API (with the potential additional advantage of not being completely hooked up to the use of the Parson library).

Additional context

Initially I'm thinking of wrapping function that are in use, or are likely to be used in this way json_value_init_object()-> G_json_value_init_object().

List (not complete) of relevant functions to wrap up :

• json_value_get_object
• json_value_init_array
• json_value_init_object
• json_object
• json_object_get_array
• json_object_get_wrapping_value
• json_object_set_boolean
• json_object_set_null
• json_object_set_number
• json_object_set_string
• json_object_set_value
• json_array_append_string
• json_array_append_value
• json_serialize_to_string_pretty
• json_free_serialized_string
• json_value_free

How to deal with Parson "types" such as JSON_Object, JSON_Array and JSON_Value, whether to wrap them too or just "re-use" them, needs to be decided.

[wenzeslaus]

What happens when the Parson's json_ functions are in the wrapper library? Won't they be still accessible in the same way (for the wrapper functions to use them) so creating exactly the same situation like now? Or are you thinking about something which makes the Parson's json_ functions sort of "static" to the wrapper library?

[nilason]

What happens when the Parson's json_ functions are in the wrapper library? Won't they be still accessible in the same way (for the wrapper functions to use them) so creating exactly the same situation like now? Or are you thinking about something which makes the Parson's json_ functions sort of "static" to the wrapper library?

The parson's own API will be internal only for libgrass_parson, which itself doesn't link to anything. Use of the GRASS parson library will only be through the public wrapper API, which will not be in conflict. So as far as I understand it, there shouldn't be any problems.

[cwhite911]

That sounds good to me. Let's also make sure to document this in the instructions for adding third-party libraries.

[NishantBansal2003]

Is this a good starting point for understanding the implementation of the above-mentioned wrapper of the JSON parser with a unique Grass API?

grass/include/grass/defs/gmath.h

Lines 57 to 62 in fe05858

	/* *************************************************************** */
	/* ***** WRAPPER FOR CCMATH FUNCTIONS USED IN GRASS ************** */
	/* *************************************************************** */
	extern int G_math_solv(double **, double *, int);
	extern int G_math_solvps(double **, double *, int);
	extern void G_math_solvtd(double *, double *, double *, double *, int);

cc: @nilason @cwhite911

[wenzeslaus]

The parson's own API will be internal only for libgrass_parson, which itself doesn't link to anything. Use of the GRASS parson library will only be through the public wrapper API, which will not be in conflict.

The API driven by includes will be. I don't know about the symbol lookup driven by linking. I don't know how that works exactly.

[NishantBansal2003]

Is this a good starting point for understanding the implementation of the above-mentioned wrapper of the JSON parser with a unique Grass API?

grass/include/grass/defs/gmath.h

Lines 57 to 62 in fe05858

	/* *************************************************************** */
	/* ***** WRAPPER FOR CCMATH FUNCTIONS USED IN GRASS ************** */
	/* *************************************************************** */
	extern int G_math_solv(double **, double *, int);
	extern int G_math_solvps(double **, double *, int);
	extern void G_math_solvtd(double *, double *, double *, double *, int);

cc: @nilason @cwhite911

Hey @nilason, could you guide me here? I’d like to proceed with this for merging #4665