On 19.4.12 16:36, Angela Schreiber wrote:
hi michi
1. workspace story
------------------------------------------------------------------------
as already stated in reply to felix/jukkas discussion in this thread
that i have a different preference regarding on the relationship
between ContentSession and JCR Session/Workspace... but i am convinced
that we can reach consensus on this once we have a better picture on
access control, permission evaluation, versioning and representation of
repository-level content as this most probably will have an impact.
Having ContentSession.getContentTree() return the whole tree is a more
general approach than returning only the tree of a given workspace. That
is, workspace operations can be implemented on top of that, where in the
other case we'd need some special workspace operations in the API. So
why? we already have the copy method on the oak-api :) IMO there is
nothing we can or want to do on the oak-jcr level with those workspace
operations. it's only a question of whether the copy-parameters consists
of 2 paths (including the workspace-address) or 2 paths and in addition
a workspace name.
Because generalising the concept of a workspace into being just the
first segment of the path is... well a generalisation ;-)
this all boils down to a questions of API granularity and content model:
Do we want to expose workspaces explicitly at the Oak api level? What
are the use cases (on that API level)? If we don't, what is the draw
back for Oak API consumers having to cope with the content model
directly?
i am particularly interested in the use cases of exposing the whole
repository as i simply don't see that except for the simplicity of
cross-workspace copy and clone.
I was mainly thinking off other clients of the Oak API. Having a general
access pattern through a path is IMO a good thing.
What about going the general way (i.e. getContentTree returns the whole
tree with all workspaces beneath it) and providing an utility class
'JCRView' in oak-core which projects the content tree to a given
workspace and 'mounts' the jcr:system node?
what is the use case of exposing how the jcr:system tree is stored
internally?
I didn't say internally. Maybe I should have written 'exposes' instead
of 'mounts'.
and did you think about the consequences in terms of access control?
versioning? query?
No but...
We have to copy with all of these things like the system node,
versioning, query, cross workspace operations anyway. So the way I look
at it is, why calling the first segment of the path workspace? What is
really the difference between
session.getContentTree("default")
and
session.getContentTree().getChild("default")
other that we have to think of an additional concept in the latter case?
2. access control restrictions
------------------------------------------------------------------------
there is one thing that we have to keep in mind when it comes to
the ContentTree interface and the information it exposes to the oak-jcr:
due to the fact that permission evaluation will be located in oak-core
the ContentTree might be incomplete. a given user may not be able
to read the root node but having access to items somewhere in the
subtree.
thus:
ContentSession session = ...;
ContentTree tree = session.getCurrentContentTree();
if the tree here really represents a node that might be problematic
(and the name seems rather misleading to me in this case).
It represents a sub-tree which in turn might contain sub-trees. As such
I like that name better than node. However, we might have different
perceptions of what constitutes nodes and trees.
however, if we look at ContentTree as an abstract point in the
hierarchy that is identified by an identifier that might work.
but then the ContentTree interface should not have methods that
actually belong to a Node... or we need the possibility to determine
if there is an accessible 'NodeState' with a given 'tree'.
second we need to have the ability to access item information
somewhere in the subtree without having to traverse (see above).
there are for sure multiple possibilities to achieve this, such
as e.g.
- ContentSession.getCurrentContentTree take (must have) a path
-> contentree was more of a node again
-> how do you assert then that transient modifications are
always persisted together since we don't want to support
Item#save() any more???
- ContentTree in addition has a method getNodeState that would
actually represent the Node. the tree was then just the
representation of the path and the modifier/access methods
should rather be moved to NodeState.
I think we don't need a separate NodeState. Isn't having navigational
methods on ContentTree sufficient? I.e. something along the lines of:
interface ContentTree {
ContentTree getParent();
ContentTree getChild(String name);
// ...
}
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.
Michael
just figure out that someone wasn't able to see the root node.
but he/she was granted all kind of access to 3 different subtrees
somewhere deep in the hierarchy. that's a use case we have to
cover.
so, i guess the content tree should provide the ability to access
a subtree without traversal (that was useful anyway).
whether or not (and how) the top or an intermediate contenttree object
was accessible if access to the corresponding jcr-Node has been denied
is something we have to find a solution for.
maybe it is feasible if we can represent the contenttree as some sort
of 'stub' (no name, no parent, no nothing) but in any case we must
be able to deny access to the corresponding JCR Node without extra
round trip to oak. in any case no access control evaluation will not
be execute on the jcr-layer.
kind regards
angela
