View Issue Details

IDProjectCategoryView StatusLast Update
0005423GNUnetotherpublic2019-04-03 16:55
Reporterschanzen Assigned Toschanzen  
PrioritynormalSeveritytrivialReproducibilityhave not tried
Status closedResolutionfixed 
Product Version0.11.0 
Target Version0.11.1Fixed in Version0.11.1 
Summary0005423: JSON helper library
DescriptionThe src/json helper library is used to convert GNUnet objects from/to JSON.
However, to convert GNUnet structs like a GNS record, it needs gnsrecord as dependency (same for other things).

Now, rest plugins residing in the respective services require JSON. But the JSON helper will require their structs as dependencies as well.

How should be avoid this circular dependency?
Should we implement GNUNET_JSON_from_* functions inside e.g. src/gnsrecord, src/identity etc?
TagsNo tags attached.


child of 0005584 closedschanzen Break up rest plugins into their respective subsystems 



2018-08-10 00:30

administrator   ~0013196

CG care to point me into a direction?


2018-08-13 08:52

administrator   ~0013205

Moved plugins to separate folder in 6371b64774428e83ff83ada88bda354356718aca

Christian Grothoff

2018-08-16 13:19

manager   ~0013211

The json logic is extensible by design, so we can either have libgnunetjson-foo sub-libraries that implement (de)serialization for certain foo-data types (especially for components that are not usually built, i.e. stuff that requires ABE, or in case of cycles we cannot otherwise break) , or in some cases change the built order to avoid cycles (as you may have done already).

So IMO the main should be built as late as possible and include support for all GNUnet data types that are built unconditionally, and everything else (cyclic or optional) should go into extra sub-libraries (like Taler does with, which just adds a few Taler-specific functions/types).


2018-08-16 13:42

administrator   ~0013214

Ok. I thought so as well.
My question was more with respect to naming.
If I have a library, let's use "abe".
If I need JSON logic for the relevant structs, is it reasonable to implement functions in the GNUNET_JSON_* namespace in src/abe ? This seems to fragment the GNUNET_JSON_* namespace.
Maybe there should be a plugin-like structure to this? So that there is a GNUNET_JSON_from_data (data, data_size) and GNUNET_JSON_parse (json, &data, &data_size, &type)? (similar to serialize/deserialize of GNS records). The logic behind it is then implemented in plugin_json_abe.c inside src/abe.
(by no means is this a reasonable blueprint)

Otherwise, the only way to do it is to have separate folders (src/json-abe) or lots of ifdefs in src/json/

Christian Grothoff

2018-08-16 13:56

manager   ~0013215

Eh, sorry, we need to discuss namespace vs. directory space.

IMO, the JSON (de)serializers can either live in src/json/, or in the case of cyclic/optional components in src/WHATEVER/. In the first case, the prefix is clearly GNUNET_JSON_*. In the latter case, we end up with an auxiliary library like libgnunetabe_json OR integrated JSON operations with the main library (i.e. JSON operations become part of libgnunetabe). The latter only makes sense if JSON functionality is _inherent_ in the use of ABE and libjansson dependency is thus mandatory (I don't think this is the case here).

So src/abe/ would usually build two libs: libgnunetabe (basic ABE operations), and libgnunetabe_json (only the JSON (de)serializers). In this case, the C symbol prefix would then be GNUNET_ABE_JSON_*, which makes it clear which subsystem (ABE) and which library (ABE_JSON) these functions come from. By sharing the _JSON_, it should be clear that this relates to the json/ subsystem.

At least that's my suggestion for now, but I'm open for better alternatives. (and we should probably update the chapter on coding conventions with whatever the final result is, to make sure it is used consistently).

Note that GNU Taler uses 'libtalerjson' and TALER_JSON_*, which makes sense as Taler uses the TALER_-Namespace, and this is the top-level all-inclusive JSON (de)serializers. Hence "GNUNET_ABE_" and libgnunetabe_ become TALER_*/libtaler.

Christian Grothoff

2019-01-26 05:59

manager   ~0013466

Martin, is this resolved?


2019-01-26 10:56

administrator   ~0013470

I "fixed" it accoring o comment #2. In the future, we might want to expose to_json functions for all our datatypes, though. Then we need to revisit this issue as we need to decide where to put the API definitions.


2019-02-17 10:35

administrator   ~0013839

Last edited: 2019-02-17 10:35

I would like to reopen this for 0.12 in order to prepare for gnunet-reclaim extraction which will require first to separate JSON and REST plugins properly into the respective subsystems.


2019-03-12 10:11

administrator   ~0014186

The rest plugins have been separated into the respective subservice again.
If new JSON objects (per subsystem) as required, they should be put into the subsystem folder as <subsystem>_json.{c,h}.
The namespace for the structs/functions must be:

Issue History

Date Modified Username Field Change
2018-08-10 00:30 schanzen New Issue
2018-08-10 00:30 schanzen Assigned To => Christian Grothoff
2018-08-10 00:30 schanzen Status new => feedback
2018-08-10 00:30 schanzen Note Added: 0013196
2018-08-13 08:52 schanzen Status feedback => assigned
2018-08-13 08:52 schanzen Resolution open => fixed
2018-08-13 08:52 schanzen Fixed in Version => Git master
2018-08-13 08:52 schanzen Note Added: 0013205
2018-08-16 13:19 Christian Grothoff Note Added: 0013211
2018-08-16 13:42 schanzen Note Added: 0013214
2018-08-16 13:56 Christian Grothoff Note Added: 0013215
2018-11-01 23:52 Christian Grothoff Assigned To Christian Grothoff => schanzen
2019-01-26 05:59 Christian Grothoff Note Added: 0013466
2019-01-26 05:59 Christian Grothoff Status assigned => feedback
2019-01-26 10:56 schanzen Note Added: 0013470
2019-01-26 10:56 schanzen Status feedback => resolved
2019-01-26 10:56 schanzen Resolution fixed => suspended
2019-02-17 10:35 schanzen Status resolved => feedback
2019-02-17 10:35 schanzen Resolution suspended => reopened
2019-02-17 10:35 schanzen Note Added: 0013839
2019-02-17 10:35 schanzen Target Version 0.11.0 => 0.12.0
2019-02-17 10:35 schanzen Note Edited: 0013839
2019-02-17 11:02 schanzen Status feedback => confirmed
2019-02-17 11:03 schanzen Relationship added child of 0005424
2019-02-17 11:03 schanzen Relationship deleted child of 0005424
2019-02-17 11:03 schanzen Relationship added child of 0005584
2019-02-17 12:46 Christian Grothoff Fixed in Version Git master =>
2019-02-17 12:46 Christian Grothoff Severity minor => trivial
2019-03-12 10:11 schanzen Status confirmed => resolved
2019-03-12 10:11 schanzen Resolution reopened => fixed
2019-03-12 10:11 schanzen Note Added: 0014186
2019-04-03 12:17 Christian Grothoff Product Version => 0.11.0
2019-04-03 12:17 Christian Grothoff Target Version 0.12.0 => 0.11.1
2019-04-03 12:18 Christian Grothoff Fixed in Version => 0.11.1
2019-04-03 16:55 Christian Grothoff Status resolved => closed