On 2012-05-25 16:54, Jukka Zitting wrote:
Hi,
On Fri, May 25, 2012 at 4:46 PM, Julian Reschke<[email protected]> wrote:
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?
I'd say so, 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.
Yes.
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.
Both for this and for the tree traversal case I think it would be
useful if we could distinguish between a node being "readable" and
"traversable", a bit like how the execute bit on directories works on
unix platforms. A non-readable node could still allow a subtree to be
accessed with proper access controls, but a non-traversable node would
in effect deny read access to the entire subtree for the affected
users.
For the purpose of generating identifiers, all ancestors up to the next
referenceable node need to be traversable, und that node's jcr:uuid
needs to be readable (otherwise we can't compute consistent identifiers).
Maybe we should consider pushing down identifier generation and lookup
one level deeper?
