IETF Logo Mail Archive

Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

Robert Sayre <sayrer@gmail.com> Tue, 18 December 2012 03:41 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15721E8041; Mon, 17 Dec 2012 19:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnL9vw0-n0JY; Mon, 17 Dec 2012 19:41:04 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id EE31821E8039; Mon, 17 Dec 2012 19:41:03 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id z2so52964wey.18 for <multiple recipients>; Mon, 17 Dec 2012 19:41:02 -0800 (PST)
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=EGBKZGwymRgwmz1g5mmLkfZC6sPY+Bv7gBwz0ttxzis=; b=a4QThT785SUeJgyQq8yCu3l87w7yos6AajJojo2rSJaCVqUsDjBIPFRZPUmqtxHtee ozKTxZgPT3YuZQ61CDU9WGk1kLNFvzx5BH0s8RNvhBsHyp8/riuJLQFP+xjyPOT1GyD7 0sQ3QLc4Dud+DiXsRxCHinCUicsJGOv/wNkoKfKnPd8G4vKAyZp3reLRSwoZHbp6Hj/i FyzO5fwQAD6s5M6jkdbuu6W82Z8f5m2isVWD9ymcocr/LiDzUrrBlPk4Z61Z5JJqABSz Tj+NMmwQDDq9SA+BL0AaCybdm8leEv8k0xTEEz/gY5PmitJONpTRMFQA2XEExuPwbf4P r3lA==
MIME-Version: 1.0
Received: by 10.194.76.99 with SMTP id j3mr971835wjw.47.1355802062898; Mon, 17 Dec 2012 19:41:02 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Mon, 17 Dec 2012 19:41:02 -0800 (PST)
In-Reply-To: <CABP7Rbd7w-7-8+q0T7WciBp6NU7c2uJjmRGiLFjxkc52P5KLdw@mail.gmail.com>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com> <CABP7RbeNsZ_rBWRjou=VG+hBhUKaOz+y1a0sSChwWiHte9znnQ@mail.gmail.com> <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6SxZRc3B_HCbw76kLe2dsRSr43r-gLpfMVnCUfJTrZdTLA@mail.gmail.com> <CABP7RbfA33huBFadMeXTTEt=MkjW8-d4DFH7+GLXGurnm9sSRw@mail.gmail.com> <CAOXDeqpPE4eNy_qJpDPdPHbCQakG9-hDcNZ3Sj9r4kWedByVzQ@mail.gmail.com> <CAChr6SwtS_=iS-k4mJm1vHjEvvGVzay5jDYeGheqsPZqO-89CQ@mail.gmail.com> <EABB8F51-C3B4-49F5-8672-5C2ABAC7043A@mnot.net> <CAChr6Sy-Xc8vC6FabFmdseR7xfQ-6t9hARunWjYgt6FqjmoBWg@mail.gmail.com> <CABP7Rbd7w-7-8+q0T7WciBp6NU7c2uJjmRGiLFjxkc52P5KLdw@mail.gmail.com>
Date: Mon, 17 Dec 2012 19:41:02 -0800
Message-ID: <CAChr6SyV-kDLYnDXXjW5GD7KZ1brBYLmvO-5TkODGtcHOf2rmg@mail.gmail.com>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Robert Sayre <sayrer@gmail.com>
To: James M Snell <jasnell@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Mark Nottingham <mnot@mnot.net>, IETF Discussion <ietf@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Dec 2012 03:41:05 -0000

On Mon, Dec 17, 2012 at 7:08 AM, James M Snell <jasnell@gmail.com> wrote:
>
> Everyone's idea of "bloat" is different.

What I meant was that the predicate additions increase the size of the
protocol messages. Your example is twice as large. The check could be
more efficiently represented in the path notation or the operation
names.

> Again, the point is, I don't see this as a problem in practice. Implementers
> that make blind edits to arbitrary docs can expect surprising results
> sometimes. That's just the way it is. There are mechanisms defined (test,
> json-predicates and conditional requests) that can make the edit more
> reliable.

Well, one way of putting it would be that the patch format makes it
difficult to ensure convergence at quiescence in OT software when
there's a change in type from array to object or vice-versa:

<http://en.wikipedia.org/wiki/Operational_transformation#The_CC_model>

There's no good reason for it to be that way, is there?

- Rob

v2.15.0 | Report a Bug | By Email