Re: [Json] serializing sequences of JSON values

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 14 March 2014 03:03 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 ED2D61A0853 for <json@ietfa.amsl.com>; Thu, 13 Mar 2014 20:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.338
X-Spam-Level:
X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 WYnQRyc4Phn1 for <json@ietfa.amsl.com>; Thu, 13 Mar 2014 20:03:02 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 597971A0700 for <json@ietf.org>; Thu, 13 Mar 2014 20:03:01 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2E32mnF002390; Fri, 14 Mar 2014 12:02:48 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 712a_ae3d_1fcc70d4_ab25_11e3_991c_001e6722eec2; Fri, 14 Mar 2014 12:02:48 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 37BFCC042B; Fri, 14 Mar 2014 12:02:48 +0900 (JST)
Message-ID: <5322714F.6080508@it.aoyama.ac.jp>
Date: Fri, 14 Mar 2014 12:02:39 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Matt Miller <mamille2@cisco.com>, "json@ietf.org" <json@ietf.org>
References: <em2c025504-6532-4513-a339-3d71c4cdfbda@helsinki> <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com>
In-Reply-To: <53222FFC.8070204@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/json/wqGOBPhl2_WgSsnU1ZDniLYtICQ
Subject: Re: [Json] serializing sequences of JSON values
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: Fri, 14 Mar 2014 03:03:04 -0000

Hello Matt,

On 2014/03/14 07:23, Matt Miller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 3/13/14, 3:23 PM, Larry Masinter wrote:
>> I wonder if there is any lesson from XMPP--  which wanted
>> sequence-of-XML-values in an indefinite length stream -- that would
>> apply to JSON. What would XMPP look like if it were redone in JSON
>> instead of XML?
>>
>
> /me exchanges JSON chair hat for XMPP enthusiast hat ...
>
> If XMPP didn't exist and we instead did JMPP, it might be a series of
> discrete objects.  However, the direction of the later "XMPP over <x>"
> adaptations (e.g., [BOSH] and [XMPP-WS]) speak toward wanting to use
> an existing transport that provides block-oriented framing around
> complete structures.
>
> Dealing with partial XML-like structures in XMPP has ranged from
> inconvenient to impractical because the vast majority of existing XML
> software has assumed a whole XML document when parsing starts.  There
> are few libraries that truly allow one to feed XML in fits and starts
> and get timely output without some amount of modification or
> preprocessing.  When the XMPP community took efforts to apply XMPP
> over other transports, the direction has so far leaned toward the
> whole documents that most implementations expect; even though the
> preprocessing required is rather small, the ability to re-use existing
> implementations without first considering oft-unpublished details was
> a very powerful motivator.

This is very valuable feedback.

As far as I understand, the problem for XMPP has at least two parts:
1) The XML document arrives in pieces.
2) Parsing is done in pieces

My understanding is that parsing in pieces is well covered by SAX 
parsers, so that the problems essentially came from 1). But problem 1) 
doesn't apply to JSON text sequences exchanged as MIME types, and it 
doesn't apply to log files as these are rarely read, and when read, that 
could just be done with something like
 > echo ']' > json-array-close.txt
 > cat logfile.json json-array-close.txt | json-parse
(using [pseudo-]shell syntax).

As for delayed exchange of multiple JSON texts, e.g. a (completely 
hypothetical) JMPP (JSON Messaging and Presence Protocol), one would try 
to use a message-oriented transport (e.g. WebSockets) and then not need 
a concept of JSON text sequences at all.

Regards,   Martin.