VSC self-documentation

[Poul-Henning Kamp]

--------
In message <CADe=ujbko6ohS7L=gYj0AhnS1vdqSa5xpFznAg2Us=G=Ee1CFg at 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
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.