View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005423 | GNUnet | other | public | 2018-08-10 00:30 | 2019-04-03 16:55 |
| Reporter | schanzen | Assigned To | schanzen | ||
| Priority | normal | Severity | trivial | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.11.0 | ||||
| Target Version | 0.11.1 | Fixed in Version | 0.11.1 | ||
| Summary | 0005423: JSON helper library | ||||
| Description | The 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? | ||||
| Tags | No tags attached. | ||||
|
|
CG care to point me into a direction? |
|
|
Moved plugins to separate folder in 6371b64774428e83ff83ada88bda354356718aca |
|
|
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). |
|
|
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 |
|
|
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. |
|
|
Martin, is this resolved? |
|
|
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. |
|
|
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. |
|
|
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: GNUNET_<SUBSYSTEM>_JSON_* |
| 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 |
