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
