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

[Phillip Hallam-Baker <[e-mail]>]

If I open up a file with an RS character in it using notepad, how is
it going to look?

Since RS is effectively an obsolete character the best I would expect
is to see ? all over the place.

Unix and Windows both came to the conclusion that the only control
characters that are used are CR, LF and TAB. And CR is only used
because the Internet adopted CRLF as the line ending sequence rather
than LF.

JSON is a text based encoding. It is not the place to attempt to
resurrect long abandoned control character conventions.



On Wed, May 7, 2014 at 4:38 PM, Nico Williams <[e-mail]> wrote:
> On Wed, May 7, 2014 at 3:12 PM, Jacob Davies <[e-mail]> wrote:
>> 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?
>
> With od(1), for example :)
>
>> ?
>
> +1 :)
>
>>> 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 "} {".
>
> Good!
>
>> 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.
>
> The RS thing should be OPTIONAL, to be used when writing entries in a
> log-like way (e.g., using O_APPEND), because of the potential for
> corruption in the face of interrupted writes.
>
>> 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.
>
> Right, writing entries with no internal newlines is easy enough for
> log writers, and hardly a problem for anyone consuming logs.
>
> Nico
> --



-- 
Website: http://hallambaker.com/