cachemgr and YAML tables

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Sun, 06 Apr 2014 12:25:00 -0600

On 04/05/2014, Amos Jeffries wrote on #squidev:

> the issue I'm most stuck at is design decision on how to represent cachemgr tables in YAML format.

> the CGI uses TSV (tab separated values) for the block of lines in a table. YAML seems less friendly.

> I have found that line format " - [ x,y,z,w, foo ] " is accepted by
> YAML but looks a bit nasty. by adding tabs around the values that can
> be compatible with the CGI interpreter.

> but I am wondering if you know of a better way, or would object to
> that above mangling in audit?

Hi Amos,

    After re-reading the "cachemgr output normalization" and "[RFC]
cachemgr style updates" threads. I think my answers are yes and
"depending on how it is implemented":

Yes, I believe the best path forward is still not unconditionally adding
dashes, [square brackets], and commas to the existing actions output
code but:

1. Adding "cache manager output" API for all actions to use when
producing the final or "presentation" output (after all aggregation and
such). Methods to write key:value, open table, write table cell, close
table, write a string "as is", and such would be a part of that API.

2. Creating and using an appropriate (TXT, YAML, etc.) formatter object
that implements API from #1. The request URL (and/or headers) determine
the correct presentation format[ter] object to create. The action code
will use that object to produce from-Squid output without knowing the
output format.

With the above approach, existing human-friendly TXT output can remain
nearly unchanged while output directed at post-processing scripts can
use YAML without being inconvenienced by human-friendly output oddities.

However, if

a) the current consensus is that Squid should NOT support multiple cache
manager output formats and should NOT preserve TXT format used by the
existing automation scripts, and

b) the chosen single one-size-fits-all format is YAML,

then your suggestion sounds good!

Please note that to implement your suggestion, you would still want an
interface and its implementation very similar to items #1 and #2 above.
You can make it using just one "YAML formatter" class, without a generic
parent and without the code that decides what specific formatter object
to create for a given mgr query. Please do not manually add spaces,
dashes, brackets, and commas to the existing mgr output code lines!

Thank you,

Alex.
Received on Sun Apr 06 2014 - 18:25:05 MDT

This archive was generated by hypermail 2.2.0 : Mon Apr 07 2014 - 12:00:13 MDT