Re: [Json] JSON Log file encoding JSON-L

[Nico Williams <[e-mail]>]

For a variety of reasons I would prefer that a log file format based
on JSON simply forbid the appearance of unescaped newlines in JSON
texts, and otherwise be just JSON sequences:

 - it's compatible with JSON sequences
 - it works with line-oriented Unix tools (e.g., wc(1), grep(1), ...)
 - aesthetically it's nice
 - it's simpler to resync: just search for the newlines (or EOF, or
offset 0) around entries that fail to parse

 - it's easy to implement because most JSON encoders I've seen (all?
I think so) have an option for producing "compact" output,
usually/always meaning no whitespace will be emitted between the
tokens that make up a JSON text -- just use this feature and that's
that

 - it even works without compact JSON encoding if you're lucky to not
have crashes and such

   Some OSes don't guarantee that writes to files will be completed
when a process is SIGKILLed.  E.g., recent Linux kernels don't
guarantee that more than one byte will be written in that case -- this
was well-intentioned in that a process could start an enormous write
that an admin might want to stop, but how would they? which is why
Linux now allows SIGKILL to terminate incomplete writes.  Therefore
power failures and system crashes are not the only thing to worry
about.

   Even with non-compact entry encodings, one can always recover with
some heuristics, and at some cost.  The biggest problem here is the
SIGKILL problem.

Nico
--