jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Oak API - a top down look
Date Thu, 19 Apr 2012 17:13:31 GMT
hi michael

>>>> that's not sufficient IMO. if the content tree presents the
>>>> "Node" than it might simply be that you don't have access to it
>>>> due to access constraints that are are being enforced in oak-core.
>>>
>>> Well the peculiarities of this is what I wanted to find out about in the
>>> questions in my original mail... Anyway, I find it odd that one should
>>> be able to access say /x/y but not /x. That is, there is no difference
>>> from having an x which you can't to nothing with but use it to retrieve
>>> its child y and being able to retrieve /x/y directly.
>>
>> even if you find it odd, there are real use case for that (in
>> contrast to the repo-view ;). maybe you can set 2 hours aside and
>> take a look at the software your employer is selling? ;-)
>
> That's not my point. My point was, that we can get the same behaviour on
> the JCR API as we currently have through the ContentTree methods as I
> sketched them earlier. Maybe you could set 2 hours aside too and think
> about this ;-)

*LOL* will do that...

as i said in a previous post i wouldn't mind if it works out with
some sort of segment-only-entry in the content tree where it was
possible to find out that no is granted here without performing an
extra check in oak... that's all. in any case we will have the
prove at the point we have the complete access control stuff
implemented.

kind regards
angela



> Michael
>
>>
>> honestly, this was the first thing we had to fix both in jackrabbit-core
>> and in jcr2spi... in the latter case it even
>> was another company that pushed to me to make that change.
>>
>> kind regards
>> angela
>>

Mime
View raw message