Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAOnkMuyRQra7OQRtk3Wbc+=EN0tuwWwFrbv8btq7nqOLxj2-w@mail.gmail.com>
References: 
 <CAAOnkMtSzc41Z267R=f5TyigfGP0vcFpGUCHooBTCviqSn2Y=g@mail.gmail.com>
	<CAOFYJNZd8PX=3QFk+Ayx=S1Mk+gAcV5t7yYsVgy4fS+k6sq69w@mail.gmail.com>
	<CAAOnkMuyRQra7OQRtk3Wbc+=EN0tuwWwFrbv8btq7nqOLxj2-w@mail.gmail.com>
Date: Tue, 3 Jul 2012 11:39:35 +0200
Message-ID: 
 <CAFYk8NkKCH7CL7VoPabuDhdzVpGAEVxru6-cLeaTa+XbJA2_4w@mail.gmail.com>
Subject: Re: Question about same name siblings and authorization
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 3, 2012 at 11:19 AM, Bart van der Schans
<b.vanderschans@onehippo.com> wrote:
> On Tue, Jul 3, 2012 at 11:06 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Jul 3, 2012 at 10:55 AM, Bart van der Schans
>> <b.vanderschans@onehippo.com> wrote:
>>> We running into a (potential) issue with same name siblings and
>>> authorization and I would like to have some feedback before we try to
>>> fix this (if needed at all).
>>
>> Your problem boils down to having "same name siblings" and
>> "authorization" in the same sentence, or perhaps even having same name
>> siblings in the first place. You're probably better off if you try to
>> avoid the SNS feature entirely.
>
> We are very aware of this, but unfortunately we are dealing with a bit
> of legacy here :-(
>
>>> Which is a bit odd, because how can the session know there is more
>>> than one item sibling? Does anybody knows what the spec has to say
>>> about this?
>>
>> The spec leaves this open by explicitly allowing access control to
>> leave gaps in the SNS sequence. It's not an elegant solution, but
>> AFAIUI nobody really considered such interactions when the SNS feature
>> was specified (IIUC it came up just as a logical consequence of the
>> XML import feature).
>
> Ah, thanks Jukka and Stefan for the quick replies.
>
> So the "compacts indices" mode for SNS is also allowed (as stated in
> paragraph $22.5), but I suspect that may take quite some effort to
> implement this in the current code base. And even then it probably
> will come at the cost of some performance.

i would guess that implementing session-local index compacting would
result in pretty nasty code. apart from that i don't see any benefit in
doing so as the current behavior is clearly spec-compliant.

cheers
stefan

>
> Regards,
> Bart