Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 98554 invoked from network); 17 Aug 2007 21:14:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Aug 2007 21:14:43 -0000 Received: (qmail 74666 invoked by uid 500); 17 Aug 2007 21:14:40 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 74648 invoked by uid 500); 17 Aug 2007 21:14:40 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 74639 invoked by uid 99); 17 Aug 2007 21:14:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 14:14:40 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mwaschkowski@gmail.com designates 64.233.166.176 as permitted sender) Received: from [64.233.166.176] (HELO py-out-1112.google.com) (64.233.166.176) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 21:14:34 +0000 Received: by py-out-1112.google.com with SMTP id u77so1279841pyb for ; Fri, 17 Aug 2007 14:14:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=n835DyCib1h/q1NZIuQQfKhQjwwDGvtohywMd2BkRHRzFBSwhxm+AiN9Rnkf96WxPxgSyk6UkdapxDGiZ1tGPrwLAEaWoWWSESscXJHXFb+uP+/ent5vnhfvDDVQy81nTSSxkyiZNDiNdnyR+WHLxLcg/A83z1QkWyIt2zZPIrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=rO0tCcQsO5w9tXGGtt59Uxdpvpm4tpQCtDdnq+VoRmSmHEE3I6M3/FoXRtLF570b6aS+hxen4U+WS32TDXoyXReiIG/13eRP4bQbH0+ky4k2d4NSO7rhZitxrxTScLIDB+1yLvqCYYTNNrRLIBiT/dEPVMT2h5MoV69qCQ0kpng= Received: by 10.64.27.13 with SMTP id a13mr6206423qba.1187385253045; Fri, 17 Aug 2007 14:14:13 -0700 (PDT) Received: by 10.65.148.6 with HTTP; Fri, 17 Aug 2007 14:14:12 -0700 (PDT) Message-ID: <76a6ebd00708171414i5adbbe7h7ff0264507320e39@mail.gmail.com> Date: Fri, 17 Aug 2007 17:14:12 -0400 From: "Mark Waschkowski" To: users@jackrabbit.apache.org Subject: Re: 3.1.3.1 Removing Items In-Reply-To: <46C46C32.8030906@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_61133_8137793.1187385252947" References: <469F7E7C.4090906@yourmail.com> <8641fd7c0707232224g55e3dc00l9724f802a0c600da@mail.gmail.com> <5f211bd50707240013k44dcb6b3p140589d15723116f@mail.gmail.com> <46C088A1.6040506@nuxeo.com> <76a6ebd00708140742o477534a9mdbcc6deaf8ae5b15@mail.gmail.com> <5f211bd50708140755t1a50d2c0nc65bf6ba56de1842@mail.gmail.com> <76a6ebd00708150917y7e713e68uc52edf6dce0c0e83@mail.gmail.com> <7919c1900708150944w121cae1ekec3e7153e35b0c64@mail.gmail.com> <76a6ebd00708151329ica726eeu90e2c4b2b66d4d77@mail.gmail.com> <46C46C32.8030906@gmx.de> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_61133_8137793.1187385252947 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline "If you want to discuss a data model change, please be clear about it, and stop discussing the API. What the API does depends on the data model, not the other way around." I think we've had this discussion in another thread already... Anyway, I'm discussing the API. JCR is an API, not an implementation. Please see: http://en.wikipedia.org/wiki/JSR-170 "*Content Repository API for Java* (*JCR*) is a specification for a Java platform APIfor accessing content repositoriesin a uniform manner. " I don't care that there are 800+ implementations out there already for content repository or the data models that each of the those implementations uses. I'm sure that consideration was made for the implementations that existed prior to the spec, but I'm also sure that not every one of those implementations could easily accommodate conforming to the spec, and thats why different levels were introduced. In any case, its the mandated behavior of the new spec that I'm trying my best to provide feedback on, which I'm actually hoping may improve it. Regards, Mark On 8/16/07, Julian Reschke wrote: > > Mark Waschkowski wrote: > > ... > > Fair enough. However, look at it from the reverse point of view, what > would > > the impact to the users of the API be if setting a property to null > DIDN'T > > remove it (assuming there was a flag that could be set to toggle the > > behavior on startup to deal with compatibility issues)? The existing > > remove() function would then be used to remove properties when not > desired, > > instead of setting properties to null and having this side-effect. I > believe > > that the API would be more intuitive to most, if not all users, the > > workarounds that we have developed wouldn't be required, and that nobody > > ... > > Again: > > the thing that's being proposed is not an API change, but a data model > change. > > If we stick with the current data model (which I'd support), then > passing a null value can either cause an exception, or cause the > property to be removed. I don't have a preference here, except for > keeping compatibility with JSR-170. > > If you want to discuss a data model change, please be clear about it, > and stop discussing the API. What the API does depends on the data > model, not the other way around. > > Best regards, Julian > > -- Best, Mark Waschkowski ------=_Part_61133_8137793.1187385252947--