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

[Jacob Davies <[e-mail]>]

On Tue, May 6, 2014 at 7:05 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> And how do you know where these control characters are?

?

> If we are going to start using obscure ASCII control characters then
> we might as well co all binary. Trying to make use of them is going to
> make printers and all sorts of editors barf.

[Citation needed] I tried it in a few places and it either didn't
render at all or rendered as a single space. Since the format requires
sequences of JSON objects, that will result in either "}{" or "} {".

Compared to the alternative, which is requiring that the logged JSON
object have no internal newlines, it seems significantly more readable
to use a character for resynchronization that is already universally
illegal in JSON texts. I suggested RS because that is the actual
intended role of that control character and it is highly unlikely that
any existing JSON emitters pass it unescaped. FF (0x0c) is another
reasonable choice - well, I think you'd want \f\n - but I'm guessing
it's more likely to be erroneously passed unescaped by existing
emitters. Editor support is probably wider, but it's sort of a misuse
of the character.

All that being said I'm less convinced than I was when this was first
discussed that the "no internal newlines or whitespace, one object per
line, use newline for resynchronization" approach is all that bad.
It's not very human-readable but it would work well with existing
tools that operate on lines in log files, and I think most emitters
have a "compact" mode where no extraneous whitespace is included. I
think picking one format is more important than which one it is.