Re: [Json] JSON for Internet messages

Tatu Saloranta <tsaloranta@gmail.com> Wed, 03 July 2013 19:21 UTC

Return-Path: <tsaloranta@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282C521F9DB2 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 12:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S015LjLS+rGu for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 12:21:52 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DAF2C21F9DA5 for <json@ietf.org>; Wed, 3 Jul 2013 12:21:48 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hq4so498762wib.2 for <json@ietf.org>; Wed, 03 Jul 2013 12:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=23JDE6vCTmtvyhNunSwFvTbNHbksaNeg1cGCFIucUcg=; b=AYRlTg5MOEzeRw7I/jLHpy/5qE8fhb250NLXlgWGAoXF/b7dUWtOSVyLh+m4syhuzl 107mBmYcRVH5A8kfyk2KxGi9NyBCiPr37Wc9qF64+HqWYMc+kV7GuY+bera+TCYXnfVb 5LA8m6VmkRfGeSGGU/qvHrH7Wp9UVtCCD+nGOypHwhc9nIaA43LM7UOtfvbGBoeO9HxX S8HkX1S7cGVUioUNb+lk3xQl6Uz+fXqQGP7YMZo8BJedBfqyOM15abfPNHoui+YNvSV3 OxYbGtZAhGLa2VauM58YNzgiGsQDHU/LsoeO34uUs/Hv2+oriYuFZsyOSD+/GWT68oIz 5cIw==
MIME-Version: 1.0
X-Received: by 10.180.206.70 with SMTP id lm6mr19145538wic.50.1372879301609; Wed, 03 Jul 2013 12:21:41 -0700 (PDT)
Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 12:21:41 -0700 (PDT)
In-Reply-To: <CAHBU6it55C5vCNLBki1LvjpWd4fANY8LdC4fzxj3a2G_+q=qSA@mail.gmail.com>
References: <CAHBU6it55C5vCNLBki1LvjpWd4fANY8LdC4fzxj3a2G_+q=qSA@mail.gmail.com>
Date: Wed, 3 Jul 2013 12:21:41 -0700
Message-ID: <CAGrxA27wLfhLXBUF6cuuFbCEJ6yJYBtG8puiHXxNcoT3xem2zQ@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=001a11c265be1790e904e0a05f6e
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] JSON for Internet messages
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 03 Jul 2013 19:21:53 -0000

On Wed, Jul 3, 2013 at 9:34 AM, Tim Bray <tbray@textuality.com> wrote:

> I think it will be helpful to put a stick in the ground:  Most of my
> professional activity centers around designing and using message-passing
> application-level APIs.  In basically all of them, the payload is JSON.
>
> So I care a lot about JSON, but I don’t care in the slightest about usages
> where the JSON isn’t being used for application-level message protocol
> payloads (are there such usages?  I'm curious).  Also, I’ve never
> encountered a scenario where the messages were of sufficient size that
> anyone gave a rat’s ass about streaming.
>
>
Large payload are commonly used for things like map/reduce jobs and search
indexing. And databases of sorts (NoSQL or traditional) are similarly
exposing large datasets where one certainly does not want to or even be
able to handle all data in memory.

There are ways to avoid problems with large Objects for many cases within
this domain, for example, by sending sequences of root-level objects.
Parsers then need to be able to handle streams of multiple Objects.
Streaming is equally important (or perhaps more so) when generating
results; for latency (as well as memory usage) reasons large result sets
are best sent in streaming manner.

Same is true for XML as well, so I don't think this is JSON-specific
question.

I might as well claim that I have rarely worked on JSON use case where
Javascript matters at all. This is a true statement, but I would not draw
conclusions from this to allege that Javascript would be largely irrelevant
for JSON data exchange.

I think part of the challenge is that for many practicioners JSON "Just
Works" well enough that they could not care less about further
standardization: and in fact the whole notion that duplicate keys are a
major problem seems like a red herring.
It has never been a problem for me, nor has there been user requests beyond
schema (and schema validator) implementors who care more. But it is
possible that perhaps this has been a significant problem for others.

-+ Tatu +-