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

If you want to use line-oriented tools, don't use JSON.  The no-newlines
rule seems really outside the spirit of JSON.
On May 6, 2014 12:01 AM, "Nico Williams" <nico@cryptonector.com> wrote:

> 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
> --
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>