Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of
 the.mindstorm.mailinglist@gmail.com designates 209.85.146.181 as permitted
 sender)
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:content-transfer-encoding:content-disposition:references;
        b=PwUV2jTksI9gMM4LUbReBHiM3ttijXHM9GmBxN48oKmGUDJsFsyePuaqmiwPHg74eRx37WBafyjKl+02Kphw4j6y7Pm8AFBGMzAhAiOY6Q1r+fT2JD6NYwzEEjzevwcZk1xzwyk+lvHUMb9VgVqMESvUk+gNXGJQWHCb8TOFZoQ=
Message-ID: <c6f400460707200118r27425742sc3063f038d217779@mail.gmail.com>
Date: Fri, 20 Jul 2007 11:18:20 +0300
From: "=?UTF-8?Q?Alexandru_Popescu_=E2=98=80?="
 <the.mindstorm.mailinglist@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Isolation level inconsistency.
In-Reply-To: <46A06850.4050303@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070719233057.7B70810FB051@herse.apache.org>
	 <46A06850.4050303@gmx.de>

On 7/20/07, Julian Reschke <julian.reschke@gmx.de> wrote:
> Hendrik Beck (camunda) wrote:
> > One more thing I want to say:
> >
> > "again you're proposing a major change to JCR."
> >
> > "Maybe it's just me, but I have no idea how that could be implemented
> > efficiently, *in
> > particular* if you don't have the luxury to develop that functionality from
> > scratch."
> >
> >
> > 1) In my eyes the public review is there to give any feedback, to discuss
> > everything and to make proposals, whether they are major changes or just
> > little remarks.
>
> That's right. The point I was trying to make (and apparently failed) was
> that this is a major change to *JCR 1.0*.
>
> > 2) I wouldn't agree that discussions about implementation details should be
> > part of a public review of a specification. Sure we should keep an eye on
> > the implementation, it has to be done at some point. But, we talk about JCR,
> > not Jackrabbit. The JCR specification shouldn't take care about
> > implementation details of one product (Jackrabbit), but it should find the
> > best way to make the specification according to people's needs and
> > requirements.
>
> Actually, I wasn't talking about Jackrabbit either.
>
> If JCR 2.0 adds requirements that are unlikely to be implemented, that's
> IMHO a problem. Either you'll end up with no implementations, or with
> broken implementations (with respect to that feature).
>
> Best regards, Julian
>
>

I agree with both you comments here. However, I do feel that the OP
may be right (I confess that I was not facing this situation so far,
but this is probably because my app is a bit different).

I would really appreciate if somebody would post on this thread a
scenario in which the current behavior is proving helpful (and I have
in mind the scenario posted here: searching for a John and getting a
Joe instead -- frankly speaking I would be totally surprised in real
life if I would be looking for my wife and getting somebody else
instead :-) ).

bests,

./alex
--
.w( the_mindstorm )p.