jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Oak API - a top down look
Date Thu, 19 Apr 2012 15:36:00 GMT
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.

> 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.

> 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
and did you think about the consequences in terms of access control?
versioning? query?

who is actually the consumer of such a complete-repository tree?
and wasn't the 'jcr-view' just the normal case?

my take on this is that the jcr-view is the regular use case.
i wouldn't want this to be treated as an edge case that is just
reflected in an utility. this should be part of the oak-api IMO.

in addition it will just add an additional level of complexity
as everything that is dealing with paths in oak-core needs to
cover both variants: the jcr:system node being part of the
path as it is stored in the mk and the other variant, where it is
just part of a jcr-path... just thinking of a query and pattern matching 
in access control.

> This way we would get both:
> a sufficiently general API

i simply fail to see the use case of that general API but
instead have a lot of question marks.
so far the only use case that i am aware of is the workflow
copy/clone... and i simply don't consider them important enough :)

>  and avoid having Oak API consumers to
> re-implement commonly needed functionality.

if it's commonly needed, why don't we simply define the API that way?

>> 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.

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

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

View raw message