Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.29 as permitted sender)
Message-ID: <4F8ECE88.2070606@adobe.com>
Date: Wed, 18 Apr 2012 16:24:08 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Oak API - a top down look
References: 
 <CAOFYJNb88iwYpX0w=yQsP_3yTTUnM3QqezBv-Dui8wPbuAOEbw@mail.gmail.com>
 <09021F9D-3C26-4C2F-989C-7F0DD8ADD229@adobe.com>
 <CAOFYJNby-N6O2Be-zgvO4Z_6xCSuMKdejs2eQR9J6Gyr6O5DXg@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNby-N6O2Be-zgvO4Z_6xCSuMKdejs2eQR9J6Gyr6O5DXg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

hi

> On Wed, Apr 18, 2012 at 8:51 AM, Felix Meschberger<fmeschbe@adobe.com>  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