hi jukka
i like the idea of having read permission enforced on the node state
level and avoid the null checks as it is a similar approach we
are currently having by the treelocation concept that michael introduced
some time ago.
the only thing i keep struggling with is: i don't want to evaluate
read access for all parent items which most probably will not be
read within the lifespan of a session but rather limit permission
evaluation to those items that are actually being accessed... which
in our use case rather resembles a random access pattern plus
1 or 2 levels at a given tree location than a simple traversal.
in other words: in order to evaluate the permission at some location
in the hierarchy with our mainly path based permission model
we somehow need to be able to provide the hierarchy information
which as far as i saw so far was missing on the nodestate api.
that's the main piece that i was missing... otherwise your proposal
make sense to me.
kind regards
angela
On 3/20/13 11:24 AM, Jukka Zitting wrote:
Hi,
On Tue, Mar 19, 2013 at 5:09 PM, Marcel Reutegger<mreut...@adobe.com> wrote:
AFAIU, NodeState was specifically designed to not require a path.
Indeed. The main rationale for the design is to avoid the cost of
having to support things like:
assert state.getChildNode("foo").getName().equals("foo");
That seems like a simple thing, but prevents optimizations like the
EmptyNodeState or the ability of the SegmentMK to reuse existing
content to avoid duplicate copies of the same data. Thus I'd be
strongly against a proposal to introduce a method like
NodeState.getPath().
However, the design is also explicitly designed so that a particular
NodeState implementation *can* keep track of the path by recording all
the child node names used in successive getChildNode() calls until the
target node has been reached. This is what for example the
KernelNodeState does and also what we could do if we pushed (read)
access checks below the NodeState interface.
The only complication there, as already discussed before, is the
inability of the current NodeState interface to handle cases where a
child node is readable even if its parent is not.
To address that case I was thinking that we could revise the
getChildNode() contract to *always* return a new NodeState even if the
named child node did not exist. Coupled with something like a new
NodeState.exists() method (that would replace the current null checks
on getChildNode() return values) this would allow us to access nodes
down the hierarchy even if their parents don't "exist" for the current
user.
For example, to access a node like /foo/bar where the parent node /foo
is not accessible, we'd have:
NodeState root = ...;
NodeState foo = root.getChildNode("foo");
NodeState bar = foo.getChildNode("bar"); // no null checks needed!
The existence of these nodes would then show up as:
assert !foo.exists();
assert bar.exists();
A nice benefit of such a design would be that the difference between a
node not existing at all or it being read-protected is entirely hidden
from higher levels, so it'll be harder to accidentally leak
information about the presence of a particular node.
BR,
Jukka Zitting
