Re: [apps-discuss] JSON patch: "test" operation

mike amundsen <mamund@yahoo.com> Wed, 30 November 2011 17:27 UTC

Return-Path: <mca@amundsen.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B43921F8BCB for <apps-discuss@ietfa.amsl.com>; Wed, 30 Nov 2011 09:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.679
X-Spam-Level:
X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Ta+RwZq3jBfd for <apps-discuss@ietfa.amsl.com>; Wed, 30 Nov 2011 09:27:16 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA4E21F8BBD for <apps-discuss@ietf.org>; Wed, 30 Nov 2011 09:27:16 -0800 (PST)
Received: by ywm13 with SMTP id 13so1064849ywm.31 for <apps-discuss@ietf.org>; Wed, 30 Nov 2011 09:27:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.38.106 with SMTP id f10mr9073363pbk.37.1322674030410; Wed, 30 Nov 2011 09:27:10 -0800 (PST)
Sender: mca@amundsen.com
Received: by 10.142.196.20 with HTTP; Wed, 30 Nov 2011 09:27:10 -0800 (PST)
In-Reply-To: <1322672952.2050.8.camel@neutron>
References: <4ED64A26.5030003@gmx.de> <1322672952.2050.8.camel@neutron>
Date: Wed, 30 Nov 2011 12:27:10 -0500
X-Google-Sender-Auth: MNXOrlWWVi5Dyv27OOe0Hqhnnlo
Message-ID: <CAPW_8m6v0wgQoMXzFFrA5bgjksWY-No3cmuJeFa1X6RJwOvctg@mail.gmail.com>
From: mike amundsen <mamund@yahoo.com>
To: "Paul C. Bryan" <paul.bryan@forgerock.com>
Content-Type: multipart/alternative; boundary="bcaec51dde39bc7c4d04b2f70bc9"
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] JSON patch: "test" operation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2011 17:27:17 -0000

Julian:

Is the thinking that _clients_ should tell servers to test an
insert/update?  IOW, clients would want to see test results?  A "dry run"
scenario?

Also, was there any talk about how servers would handle failed tests (HTTP
Response code, etc.)? If one or more tests fail, would the server have the
option of making the changes and then returning a list of success/fail
information?


mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Wed, Nov 30, 2011 at 12:09, Paul C. Bryan <paul.bryan@forgerock.com>wrote:

> **
> Yes, assert/equals/test has been mentioned in the past. As you point out,
> HTTP preconditions to handle this to some extent. I've avoided adding it
> thus far mostly because I haven't had a single concrete use case outside of
> HTTP. Given at least the pattern of multiple requests wanting to test a
> value for equality, I think I have enough data to add it to the next
> revision of the spec. Consider it added.
>
> Paul
>
> On Wed, 2011-11-30 at 16:22 +0100, Julian Reschke wrote:
>
> Hi,
>
> this came up during discussions of patch formats on the Apache
> jackrabbit-dev mailing list:
>
> Would it make sense to add a "test" operation that allows checking the
> state of the JSON object to be modified?
>
> It would be consistent with other diff formats that use context
> information in order to check whether the patch "cleanly applies".
>
> An example would be:
>
>     [
>           { "test": "/vsn", "value" : 17 },
>           { "replace": "/vsn", "value" : 18 },
>           { "replace": "/balance", "value": 1234 }
>     ]
>
> And yes, concurrency control can also be achieved using conditional HTTP
> methods, but that doesn't mean that they don't make sense in the patch
> format as well.
>
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>