Changes

Jump to navigation Jump to search
Line 26: Line 26:     
=== result json ===
 
=== result json ===
 +
 +
==== field names ====
 +
For the naming of the fields of the results json the following principles are used:
 +
* Typing - the to expected type of the values is encoded in the field names, by a string at the end:
 +
** _tags - expect a String array;
 +
** _n - expect an Integer;
 +
** _t - expect a time in seconds since ?, encoded as Integer;
 +
** _f - expect a float;
 +
** none - the default will b a String
 +
 +
==== platform specific naming issues ====
 +
* Swift: it should be as easy as possible to decode a json with the standard Swift-libraries.
 +
** no "-", which are not allowed in Swift variable names;
 +
==== comments ====
 
* The json seems to have two user groups: OFF itself and end users (apps). Can the json be split in two section that correspond to these groups as well? Not sure whether this is a good approach.
 
* The json seems to have two user groups: OFF itself and end users (apps). Can the json be split in two section that correspond to these groups as well? Not sure whether this is a good approach.
 
* The json can be more structured, so that it is more readible for a viewer, but also from an parsing interpreting point of view. I.e. everything that corresponds to packaging goes together.
 
* The json can be more structured, so that it is more readible for a viewer, but also from an parsing interpreting point of view. I.e. everything that corresponds to packaging goes together.
3,393

edits

Navigation menu