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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev