

Labeled Tab-separated Values - naoya
http://ltsv.org/

======
beering
So what is the purpose of replacing a common format with one that wastes space
repeating labels? Many tools already support combined format, and you can look
up the fields in the config if you really can't figure it out on your own.

Also, this linkbait title is just asking for a mod edit.

~~~
hcr
It's difficult to extend the combined format, despite the demand to output
more information, like response time, to access logs is increasing.

~~~
beering
I'm not sure I parsed your comment correctly, but it's trivial to modify the
logging format to add things like response time. "%D" for Apache will add
response time.

This is orthogonal, anyways, because if you can add more information with a
label, you can add it without a label too.

Edit: I apparently missed your point. The issue about being able to modify the
logging format at arbitrary times without breaking tools seems to be the main
concern. Do people typically change their Apache logging format from time to
time?

~~~
hcr
Yes, I think. There is no doubt about increasing the importance analysing of
access logs.

Some people, including me, have experiences to customise parsers after
expanding combined format with several fields. It's annoying to re-write
regular expressions for parsers of tools we use when changing log format and
to remember the meaning and order of expanded fields.

With LTSV, parsers does not need to be modified in that cases. Easy to expand
logs and easy to process them with labels.

------
bwooce
Ok, it's sensible to make these logs easier to parse.

I don't understand why an entirely new Tag-Value scheme was invented though,
and this article doesn't attempt to justify it. Maybe it's not new and I just
haven't heard of it?

Why not use: JSON ASN.1 BER Or any other scheme with existing, mature,
encoders and parsers.

~~~
tingletech
A lot of tooling, especially in legacy processes, is based on record-per-line
formats based on semi-specified formats such as tab separated value, comma
separated values. The advancement here is that rather than using positional
values, the values are labeled. The use case for this is if you want to make
some legacy process (like some crazy bash script some sysadmin wrote up 8
years ago) and tweak them in a way that you can add and remove columns from
text files more easily.

------
tingletech
I think this is sort of clever. Parsing is simple (split the line on tab, no
`:' in the label, no escaping) and you can add/remove/re-order the input rows.
By the time you gzip it up it seems like repeating the labels on every row
would not add that much weight.

