On 2012-05-22 09:32, Angela Schreiber wrote:
> hi julian
>
>> 4a) Note that this assumes that we "walk" the tree (for some value of
>> "walk") without being stopped by access control.
>
> not totally sure if i understand what that means. we definitely
> can't rely on the ability to walk the tree. similarly i plan to
> enforce access control on the oak-layer. in other words: authorization
> will not be built on top of the jcr-layer as we have it currently
> in jackrabbit-core. instead i will enforce it underneath the oak-api.
>
> kind regards
> angela
Related to this:
For OAK, we need to decide how to generate identifiers for nodes that
aren't referenceable.
In Jackrabbit, we simply assign UUIDs to every node, referenceable or not.
My assumption was that we don't want that here, right?
The obvious alternative is to use the identifier of the closest
referenceable ancestor, and combine it with a relative path. That would
make the identifier stable across certain move/rename operations.
If we want to do this, we'll need to walk the tree up, and consider what
it would mean for a parent node not to be readable.
Best regards, Julian
|