From dev-return-32932-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Sun Nov 6 19:11:33 2011 Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DBFD29073 for ; Sun, 6 Nov 2011 19:11:32 +0000 (UTC) Received: (qmail 40504 invoked by uid 500); 6 Nov 2011 19:11:32 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 40463 invoked by uid 500); 6 Nov 2011 19:11:31 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 40456 invoked by uid 99); 6 Nov 2011 19:11:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2011 19:11:31 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fmeschbe@gmail.com designates 74.125.82.170 as permitted sender) Received: from [74.125.82.170] (HELO mail-wy0-f170.google.com) (74.125.82.170) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2011 19:11:22 +0000 Received: by wyg10 with SMTP id 10so8239320wyg.1 for ; Sun, 06 Nov 2011 11:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=4hQ79htEt1Wf8Uozx/fNrLdpI5P/DG+i21Ld50umvCo=; b=l5QS8kBw+oE/NU0mMs1EUDZxCArY80Z2dOdm0uvy6hYL/+e70VnvOAYscEGagahW2K BcdFcJo9idg/W5eHJ49yy9nCzOzZP7fNR577RzvzaQsuqQyMCl+sqOUrxT4mw9Xi6Kol obnk8DROs3RuGu2pjr/FMGZ5QjsRRHVV4H+RU= Received: by 10.227.208.77 with SMTP id gb13mr28741156wbb.4.1320606662140; Sun, 06 Nov 2011 11:11:02 -0800 (PST) Received: from fmeschbe-mac.meschberger.ch (cable-static-182-112.eblcom.ch. [87.102.182.112]) by mx.google.com with ESMTPS id b5sm24882912wbh.4.2011.11.06.11.11.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 11:11:01 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: =?iso-8859-1?Q?Re=3A_=5BJackrabbit_Wiki=5D_Update_of_=22Jsop=22_?= =?iso-8859-1?Q?by_MichaelD=FCrig?= From: Felix Meschberger In-Reply-To: <4EB16E3F.5050008@apache.org> Date: Sun, 6 Nov 2011 20:11:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111102114348.89549.98093@eos.apache.org> <85A74F6C-9D82-477E-AE9E-862A3C8390A3@adobe.com> <4EB16E3F.5050008@apache.org> To: dev@jackrabbit.apache.org X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on apache.org Hi, Am 02.11.2011 um 17:22 schrieb Michael D=FCrig: >=20 >=20 > On 2.11.11 16:07, Felix Meschberger wrote: >> Hi, >>=20 >> Thanks Thomas and Michael for documenting your JSOP use. >>=20 >> I have one comment: >>=20 >>> + DIFFS ::=3D (ADD | SET | REMOVE | MOVE)* >>> + ADD ::=3D "+" STRING ":" (OBJECT | ATOM) >>> + SET ::=3D "^" STRING ":" ATOM >>> + REMOVE ::=3D "-" STRING >>=20 >> I see there is ADD support for properties but no REMOVE support. I = think ADD support is not needed, because SET does it all. This not only = makes the syntax cleaner but also its use. >>=20 >> If we keep ADD support for properties, we would -- for symmetry = reasons -- have to add REMOVE support for properties. But this is not = possible (since properties and nodes can have the same name). But then = REMOVE support for properties would not help anything, since setting a = property to null is the same. >>=20 >> I look at this from the perspective of converting a JSOP document (or = string or text or file or HTTP request) into a series of JCR API calls. = In such a scenario, I would have easy support for SET and REMOVE but = would have two issues for supporting ADD: >> (1) I would have to inspect the argument to ADD to find out whether = it is an addNode or setProperty call >> (2) I would have to handle SET and ADD-for-property with the same = setProperty call >=20 > The intended use is not only for HTTP calls but rather also for HTTP = replies. In the case of a HTTP reply carrying a change log, how would = you distinguish setProperty from adProperty? I.e. generate the correct = JCR observation events from that change log? Right. I wonder, why this would be of interest ? (and yes I know that = there is a PROPERTY_ADDED and a PROPERTY_CHANGED event type in = observation, but ...) Regards Felix >=20 > Michael