FreeWRL / FreeX3D 4.3.0
fw_cson.h
1/*cson C json toolkit
2needed for:
3- SSRserver (SSR: server side rendering) to communicate with html client:
4 - viewer postion and orientation in the most absolute coordinates
5 - ie world coords (.pos, .quat transformed via View part of ModelView matrix)
6 - or if geo nodes, then geographic coordinates
7 - placemarks in absolute coords
8 - tree of placemarks - so each SSR responsible for its own placemarks, and zoneserver aggregates them
9 - SSR_API in general
10vs. xml toolkits:
11- about the same, except in libfreewrl we aren't doing any xml generation, just parsing,
12 - so we would need xml generation api when responding in json, or requesting via json in C of another SSR
13- benefits of doing json vs xml
14 - its a new learning stretch for freewrlians
15 - may need json for EAI revamp (if we had JSON 15 years ago, EAI might have used JSON?)
16 - may need json for web3dz (like x3z) for supporting web3d.org new json format
17vs. json-c, jansson, other json c toolkits listed on http://json.org/:
18- cson about the same as jansson -toss up- got cson running first, others may work, not investigated
19- cson meets all our requirements:
20- 64bit doubles, which we need for absolute coords for large geographic scenes
21- both generator (for writing ie sending back to html client, requesting from another SSR)
22 and parser (for reading POST from client, or sniffing for position)
23- single .h, .c so no .lib needed, just add .c to existing project (because we are suffering lib exhaustion)
24 (cson amalgamation. json-c, jansson are .lib)
25- MIT or equivalent license, so can fall within fw LGPL license constraints
26- 32 and 64 bit compilation
27- documentation, internal docs, example / tutorial / test code
28 (jansson had more testsuite, but a bit light on docs. cson had just enough to get going,
29 and good internal docs for hacking)
30- possibie session management in future (cson and jansson seemed to have something,
31 cson would need re-amalgamation to get session layer)
32- attempt to minimize memory fragmentation: (cson claims effort)
33 all the toolkits seem to parse to a tree of malloced objects (not sax-style callback parsing)
34 then you walk the tree to do your object-to-my-appdata gathering or searching/sniffing
35 then call a cleanup(root_object) to erase the object tree
36 generally we are relying on malloc/free to re-use and coallesce fragments produced
37
38dug9 downloaded cson from http://fossil.wanderinghorse.net/wikis/cson/?page=cson
39May 23, 2015 using the instructions given for downloading from trunk on fossil
40logged in as anonymous user, and picking the top trunk revision, and
41finding a download .zip link
42and amalgamated (packed into single .c, .h) using its bash script
43sh createAmalgamationCore.sh
44found in /cson trunk
45(dug9 ran .sh under cygwin64 on windows)
46did some x64 touchups for 'compiler noise reduction' directly in the amalg .c,
47-- would need to redo it (about 5 minutes work) if re-amalgamating, or
48 do it 'upstream' (generally x64 size_t gets downcaste to int or even to char (8 bit signed int +- 127)
49*/
50//As per instructions in cson.h, for double/64bit floats
51//needed for GIS / geographic coordinates
52#define CSON_DOUBLE_T_PFMT ".8Lf" // for Modified Julian Day values
53#define HAVE_LONG_DOUBLE
54#include "cson_amalgamation_core.h"