jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Oak API - a top down look
Date Thu, 19 Apr 2012 16:25:13 GMT


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

Mime
View raw message