2018-08-18 21:57 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005423GNUnetotherpublic2018-08-16 13:56
Assigned ToChristian Grothoff 
PrioritynormalSeverityminorReproducibilityhave not tried
Product Version 
Target Version0.11.0Fixed in VersionSVN HEAD 
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.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]



schanzen (developer)

CG care to point me into a direction?


schanzen (developer)

Moved plugins to separate folder in 6371b64774428e83ff83ada88bda354356718aca


Christian Grothoff (manager)

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 libgnunetjson.so 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 libtalerjson.so, which just adds a few Taler-specific functions/types).


schanzen (developer)

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/Makefile.am


Christian Grothoff (manager)

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.

-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 => SVN HEAD
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
+Issue History