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

Nico Williams <nico@cryptonector.com> Tue, 06 May 2014 19:41 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF461A018D for <json@ietfa.amsl.com>; Tue, 6 May 2014 12:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPc2EL8_p3Cg for <json@ietfa.amsl.com>; Tue, 6 May 2014 12:41:56 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 497331A016C for <json@ietf.org>; Tue, 6 May 2014 12:41:56 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 9D37567C06B for <json@ietf.org>; Tue, 6 May 2014 12:41:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=TwBSj8XDuvzZPGwv221/ tDjKWno=; b=gezGqvrXanC2eiHh/gBSVDuLc5aWT+YM92A7tHjDSog8bukOAowh UGfVXesC62If9BQhAs66F8dimejiWR12z5t9z17r7OU/TzI9hnepjgunAIIufho6 DbCw5vkP5WlpaH5vnTkq4RzI6In0dC4aRHnP4ZcXdfTyEKoDUzWupAk=
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 4F4C567C057 for <json@ietf.org>; Tue, 6 May 2014 12:41:52 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id x13so3405187wgg.22 for <json@ietf.org>; Tue, 06 May 2014 12:41:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.221.8 with SMTP id qa8mr3900984wic.39.1399405311033; Tue, 06 May 2014 12:41:51 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Tue, 6 May 2014 12:41:50 -0700 (PDT)
In-Reply-To: <20140506192203.GT5011@mercury.ccil.org>
References: <CAMm+LwjB-51z4GoeC0riehmJg1HAddmLAyfMsVOCVM80i=RiMA@mail.gmail.com> <CAK3OfOgX06vkOS1+CJhsptMAvm+KX1HgB2=34ubxUCtHNVnx=A@mail.gmail.com> <CAHBU6is7g6ecwupv-N7wW+VTN_bZL71zbHYj=ePq=iqmk=gUwQ@mail.gmail.com> <20140506192203.GT5011@mercury.ccil.org>
Date: Tue, 06 May 2014 14:41:50 -0500
Message-ID: <CAK3OfOiToeQVpROPj+fsfYtjM=CNMpsBGGEWE2OvL3HicCMMCg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: John Cowan <cowan@mercury.ccil.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/FKZjkBPpDlShNxykIC0ChkkNTI4
Cc: Phillip Hallam-Baker <hallam@gmail.com>, Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] JSON Log file encoding JSON-L
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 19:41:57 -0000

On Tue, May 6, 2014 at 2:22 PM, John Cowan <cowan@mercury.ccil.org> wrote:
> Tim Bray scripsit:
>> If you want to use line-oriented tools, don't use JSON.  The no-newlines
>> rule seems really outside the spirit of JSON.
>
> I think they fit together quite well, with each line a separate JSON
> value.  It's not like it's hard to eliminate whitespace newlines and
> escape significant ones (if any) when doing JSON output.

Right.  Eliminating internal newlines in JSON texts is just an
s/\n//g!  But I wouldn't require it, just encourage it, at least as
long as we can develop a heuristic for recovering from truncated
writes (see separate reply).  But I'd be OK with requiring it too
since s/\n//g is trivial.

Nico
--