backend/director admin states

[Dridi Boukelmoune]

>>Maybe we should do that the other way around? Have all CLI commands
>>reply with a JSON data structure, and CLI consumers like varnishadm,
>>varnishtest or varnishd -d be able to output it in plain text (with
>>this code centralized in libvarnish and exposed in libvarnishapi).
>
> I thought about that, but didn't move on it, as I didn't want to
> write all the code myself ;-)

I experimented with this a while back and tried this:

- have a CLI commands reply with a JSON payload
  - same as today: fixed-length size, newline, payload
  - includes metadata such as the response status
- JSON payload includes the "plain text" renderer's name
  - example: "backend.list", "backend.list -p" etc
  - one per command plus variants that change the output format
  - didn't go as far as plain text rendering
- replace the response JSON payload with custom byte code
  - the render chooses between JSON or text rendering
  - byte code is JSON-like, but easier to parse
  - one generic JSON renderer for all commands
  - started experimenting with plain text conversion
- code generation from a schema for each output type
  - example: "backend.list", "backend.list -p" etc (same as before)
  - defensive assertions that let us know when we break the output
  - the idea was to start actually versioning the CLI from 2.0 on
  - and at least bump y in 2.y when we add stuff to the CLI

I never completed the last experiment because the time I allocated
eventually ran out and I lost motivation to nail down the schema part.
This was in the varnishreload [1] time frame, when I realized that
changes to the CLI broke the reload scripts we ship in the [4.1,5.x]
series and since we were maintaining them out of tree we had no easy
way to keep track of that. Which is why I also wanted to import
varnishreload upstream and have proper coverage.

I have thrown the code away, but the idea stuck. And it was a fun
experiment :)

Dridi

[1] https://github.com/varnishcache/pkg-varnish-cache/pull/70