Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <5152E6EB.8040405@apache.org>
Date: Wed, 27 Mar 2013 12:32:43 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Some more benchmarks
References: 
 <CAOFYJNb4cMhdBX1v0krsNtiWCC83MB74V0izs7Uz0KnzaiYMtQ@mail.gmail.com>
 <CAOFYJNZs1S-BgtffT360=wLeMTGynXBXhwi2Rt0ok6wmEvK_6Q@mail.gmail.com>
 <5152E241.1000500@apache.org>
 <CAOFYJNYz6LzPcLSKDxWbfQRdSxB=_+z0BN68t7RogC_n-GNdUA@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNYz6LzPcLSKDxWbfQRdSxB=_+z0BN68t7RogC_n-GNdUA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit


On 27.3.13 12:21, Jukka Zitting wrote:
> Hi,
>
> On Wed, Mar 27, 2013 at 2:12 PM, Michael D�rig <mduerig@apache.org> wrote:
>> IIUC you propose to not validate paths in the read case but rely on the
>> downstream code to fail. Might be worth a try. However we'd need different
>> path parsing then for the read an the write case since circumventing path
>> validation for the write case is most certainly not the right thing to do.
>
> We already have the NameValidator that ensures that all (non-hidden)
> names stored in the repository are valid. As a consequence also all
> existing repository paths are valid.

That's right. The easiest thing is to try it out, remove pre-emptive 
path validation and see what breaks. I have the vague memory that there 
were some overly picky TCK tests which required us to put this upfront 
validation in. However, a lot of time has past since then so it might be 
a good idea to have another look.

Michael