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

If people want line mode then they probably want something like this:
http://www.w3.org/TR/WD-logfile.html

What I don't like about the W3C log file format is that every entry
has to have every column stated. Which makes it rather inconvenient
for tracking occasional errors. Most cases I just want to log the
source IP and the resource recorded. But if there was something
strange going on then I would probably want the full header set and
more.

If the information is in the logs then people will develop tools to
manage them. Its not like grep and its ilk are fixed and immutable.

One addition that I should probably make is to reference the W3C
specification as one possible source of JSON tags. That way tools can
easily support either format:

So this:

#Version: 1.0
#Date: 12-Jan-1996 00:00:00
#Fields: time cs-method cs-uri
00:34:23 GET /foo/bar.html
12:21:16 GET /foo/bar.html
12:45:52 GET /foo/bar.html
12:57:34 GET /foo/bar.html

Would become:

{ "Version": 1.0,
  "Date": "12-Jan-1996 00:00:00"}

{"time": 00:34:23, " cs-method" : "GET", "cs-uri": "/foo/bar.html}
{"time": 12:21:16, " cs-method" : "GET", "cs-uri": "/foo/bar.html}
{"time": 12:45:52, " cs-method" : "GET", "cs-uri": "/foo/bar.html}
{"time": 12:57:34, " cs-method" : "GET", "cs-uri": "/foo/bar.html}

Fun fact: the W3C log file specifies the time as GMT, not UTC and this
was not a mistake. At the time there was a possibility that GMT would
deviate from UTC by dropping the leap second idiocy and fixing to TAI.
Making corrections on the order of fifteen seconds a century is really
a piffling waste of time when solar time varies by five minutes over
the course of a year.

Of course now that the shutdown of ITU is a medium term possibility,
this might well be revisited.

On Tue, May 6, 2014 at 10:20 AM, Tim Bray <tbray@textuality.com> wrote:
> 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

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