Is supporting pretty printed (multi line) JSON worthwhile?

[chrisdew]

pros:

• more flexible input is often a good thing
• allows use of JSON libraries which only support pretty printing
• more readable display of output when connecting via netcat/telnet

cons:

• bad input breaks decoding - the current decoder cannot tell the difference between an incomplete JSON message and bad input - my clever hack to continue using JSON.parse isn't so clever in practise (I do have a work around, but the implementation is not trivial and trivial implementation is a major point using Line Delimited JSON).

[hoegertn]

Sorry for my late answer. I think we could drop PrettyPrint support because the parser doesn't need to be JSON aware in this case.

[hoegertn]

If we don't support PrettyPrint JSON we can use \n as line delimiter instead of \r\n

What is your opinion?

\cc @chrisdew

[chrisdew]

Yes, I'd be happy to drop pretty print support.

I've always thought that we should output \n (0x0a) as the separator, but be tolerant of '\r\n' on input.

I don't understand how the choice of separator is linked with pretty print support.

[hoegertn]

The problem with pretty print support is, that we need a stream parser to find JSON objects. If we use one line JSON only we can split at newlines without parsing the JSON.

[dominictarr]

It's recently occured to me that you can have pretty printing in line delimited json if you use \n\n as the delimiter. Usually, json libraries produce output without consecutive newlines (that I have used, at least) and of course, json without extra whitespace will still work too.

The only (slight) difficulty is \r\n\r\n, but that only makes the splitter silghtly more complicated.