VIP23 (VSL refactoring) design sketch

[Nils Goroll]

Hi,

I am +1 (or more, if I got more votes) overall, in particular, the incremental
approach seems to make a lot of sense to me. Depending on the state of the rest
of varnish-cache core, I would try get this into production ASAP as I have been
for the last couple of years.

Some additional points:

- It would make a lot of sense to include the field definitions for VSL clients
in a VSM segment such that log clients do not need to be recompiled when we
change fields.

- This would also pave the way for possible future dynamic VSL records (added
while varnishd runs, referenced as "VMOD log meta-data" in VIP23). At some
point, phk mentioned he would see them as a requirement for H3, but last I know
this is not the case, so we can put this to the end of the list. Yet we should
head into the right direction to eventually get there.

- We should make it clear that the VSL format does not constitute an API, so log
access is only supported by using the vsl client in libvarnishapi

- We might want to consider making the "file" format written by varnishlog -w an
API, but I guess the advantage over libvarnishapi as the API is pretty minor.

- Geoff, You mentioned once over a burger that the actual binary representation
of doubles is not standardized. By the same argument you give for the byte
order, I do not think that this bears any practical relevance for now, but we
might want to at least mention this and, for future cross-platform support,
might have some kind of "this log uses that representation" info similar to the BOM.

Nils

-- 

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/

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