hi
On Wed, Apr 18, 2012 at 8:51 AM, Felix Meschberger<[email protected]> wrote:
IIUIC there is no notion of a workspace here, right ? So to implement JCR
workspaces,
those might be to top level ContentTree below the root ?
We can handle this in two ways:
1. Specify the workspace name as a parameter to either login() or
getCurrentContentTree().
2. Have the root ContentTree represent the entire repository with
workspaces below it as subtrees.
Personally I'd prefer option 2 since it makes it much easier to handle
cross-workspace operations, but there are complications with login()
that's in Jackrabbit 2 more or less workspace-specific.
while is see that 2 may ease the implementation of cross-workspace
operations i am not convinced if that justifies the drawback
that i can see with that approach. jukka, do you have other use
cases in mind that would benefit from that approach?
since we plan to have version operations being exposed on the oak-api
there imo only non-version operation use-cases left which are limited to:
- Workspace.copy
- Workspace.clone
- maybe Workspace.create(String, String)
following some preliminary concerns from my point of view:
- at a first glance ContentSession sounds like a perfect match
to the JCR Session
- in fact a given JCR session never accesses content from a
different workspace, except from the workspace name and i am
not sure if exposing that content to the jcr-implementation was
actually needed (or a good thing to do).
what we do need imo is the possibility to execute cross-workspace
operations in an efficient manner. from my point of view the
execution itself was the responsibility of the oak-api implementation.
e.g. having an extra workspace name param in the corresponding methods
would most probably serve that need.
- i am not convinced that mapping the /jcr:system node that contains
repository level information should be the responsibility of the
oak-jcr layer... in the light of having a sling oak-core and
multiple clients of the oak-api i would prefer to delegate that
to oak core. in addition it was then an implementation detail
of oak-core how and where the data exposed under /jcr:system are
maintained internally. exposing that structure looks like asking
for troubles.
an alternative approach that would expose the jcr:system node
multiple times on that repository-content-tree felt even worse to me.
- in jr2 users and access control are bound to a specific workspace.
as long as we have very strong arguments against this, i would
definitely want to have a backwards compatible implementation in the
first release and i am not sure if it was feasible to achieve with 2.
on the other hand going for 1 wouldn't prevent us to implement any
alternative approach.
- JCR query statements are execute on the oak-core layer and are
always bound to a particular jcr-session/workspace context.
without having thought about every single detail i have the
impression that 1 was the better approach here. maybe thomas
can comment on this.
kind regards
angela
