Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation

Julian Reschke <julian.reschke@gmx.de> Tue, 20 March 2012 16:12 UTC

Return-Path: <julian.reschke@gmx.de>
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 AEAEA21F860B for <apps-discuss@ietfa.amsl.com>; Tue, 20 Mar 2012 09:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.386
X-Spam-Level:
X-Spam-Status: No, score=-104.386 tagged_above=-999 required=5 tests=[AWL=-1.787, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 hyXypou8wOD9 for <apps-discuss@ietfa.amsl.com>; Tue, 20 Mar 2012 09:12:41 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BAFDC21F85F3 for <apps-discuss@ietf.org>; Tue, 20 Mar 2012 09:12:40 -0700 (PDT)
Received: (qmail invoked by alias); 20 Mar 2012 16:12:39 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 20 Mar 2012 17:12:39 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/IYHtyAnzIYE8Se4hH4Xj1HgZW3nu67iSnyJ2oMU xVDycJqabpzUmX
Message-ID: <4F68AC76.40904@gmx.de>
Date: Tue, 20 Mar 2012 17:12:38 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Paul C. Bryan" <paul.bryan@forgerock.com>
References: <4ED64A26.5030003@gmx.de> <BC564D94-6D00-4D63-863A-8AAD00E57B3A@tzi.org> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de> <1325222688.18477.25.camel@neutron>
In-Reply-To: <1325222688.18477.25.camel@neutron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] more feature requests, was: 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: Tue, 20 Mar 2012 16:12:41 -0000

On 2011-12-30 06:24, Paul C. Bryan wrote:
> On Thu, 2011-12-29 at 16:40 +0100, Julian Reschke wrote:
>> Hi there,
>>
>> in discussions in Apache Jackrabbit space, two more features have been
>> mentioned as potentially useful:
>>
>> 1) The ability to send additional data along with the actual patch; such
>> as a plain text string describing the change (think "commit" message),
>> or user information.
>
> I've had a few thoughts here.
>
> First, I think commit messages should probably be out of scope for JSON
> Patch specifically. That said, we should allow the ability to build on
> the specified format, allowing for extensions, including additional
> (more domain-specific) operations.
>
> I'm generally against the idea of using out-of-band metadata such as
> header fields in an HTTP request, mostly because it ties metadata to the
> transfer protocol rather (what I believe rightly should be tied to the
> document).
>
> I'm interested in feedback on the possibility that I add text stating
> that if an operation cannot be determined for a given patch object, then
> an implementation should ignore it. Thoughts?
> ...

That's exactly the question we need to answer; is the extensibility 
model "must understand" or is it "must ignore"? In the latter case, 
people can define their own operators, such as "commit-message". But of 
course it would make it harder to define new operators later on.

If JSON had a comment syntax there would be a simple, although a bit 
hacky way to extend the format. But it does not...

Best regards, Julian