-------- In message <CADe=ujbko6ohS7L=gYj0AhnS1vdqSa5xpFznAg2Us=G=ee1...@mail.gmail.com>, "Devon H. O'Dell" writes:
>In case JSON ends up being a thing, [...] >Unsure whether strict correctness is required, but it certainly can't >hurt (especially if folks end up building e.g. VMODs on top of it). Thus inspired I just tested my code[1] agains the testsuite, and after one small tweak[2] it passes all the Yes/No tests. The "i_" and transform testcases gets various results: I don't transform numbers to C numeric types, so I don't find all the ieee64 overflows, and I'm not being anal about unicode either. > It's a streaming parser [...] It's ~700 LOC with header files, > and supports custom allocators. That's not a bad payback for a couple hundred lines of code. For the specific case of VCC/VMOD "symbol tables" and VSC (and VSL?) descriptions, the JSON won't be streaming, and I don't see why varnishstat/log would ever need custom allocators. For this prototyping run I'll hang onto my own code - primarily because it is already written in "varnish style" and uses vqueue etc, but once I get it working I'll circle back and try pdjson also. > In case JSON ends up being a thing, [...] ... we will have to decide if we expose the "raw" JSON parser in libvarnishapi, or if it is just used internally to implement the VSM/VSC/VSL APIs we expose. Like VGZ, I think I am inclined to not expose it, in order to not grow our APIs beyond our support-capacity. Poul-Henning [1] http://phk.freebsd.dk/misc/json.c [2] I my check for control-chars in strings I forgot that char is signed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
