VIP23 (VSL refactoring) design sketch

[Geoff Simmons]

I'm not sure if we have a consensus, but I'd like to summarize what I've
understood from the conversation so far. I at least would be willing to
go ahead on this basis.

- The "source of truth" and generation of code and docs for SLT tags
follows the model of .vsc files and the vsctool. So data about the tags,
including the new metadata, live in .rst-like sources, from which a
Python tool generates code and docs. This replaces current
include/tbl/vsl_tags*.h.

- New VSL*() code writes binary data to log records. They take
printf-like format strings (which can be generated from the SLT sources)
and varargs, so that the order and types of the args can be checked at
compile-time. But the new VSL-binary code doesn't hand off formatting to
the library printf family; it runs through the format and the varargs,
copying data into the log record.

- Code in the VSL client API extracts and formats data from log records.
The client API encapsulate details about the internal structure of
binary records -- the binary format is not public.

The VSL-binary code will obviously be hot code, and will have to be
efficient. But IMO the first PR should not overdo optimization. The
emphasis should be on correctness and good design, and the PR should be
a reasonable but not exaggerated effort to make it fast. As always, we
optimize after testing and measuring.

Comments welcome again!


Best,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20190411/151237ce/attachment.bin>