Workspaces, once more

[Jukka Zitting <ju...@gmail.com>]

Hi,

We discussed our options for (not) implementing workspace support a
few times in the past, but the outcome so far has been to postpone the
final decision and do just the minimum amount of work to keep all our
options open. As we now get closer to production-readiness, I think
it's time to finally make this decision. Here's what I propose:

We won't support workspaces in the full JCR sense (shared jcr:system,
cross-workspace operations, etc.). However, we do allow a repository
to have more than one workspace, each workspace being it's own
"mini-repository" with it's own user accounts, node types, version
histories, etc. Instead of a one-to-one mapping between the JCR
Repository and the Oak ContentRepository, the mapping would be
one-to-many with the workspace name as the key.

Why should we do this? Here's my rationale:

1) Implementing full JCR workspace support requires a lot of
non-trivial work, which touches and complicates much of our existing
functionality.

2) We haven't come across many major deployments or use cases where
full workspace support would be needed. The few cases where it is used
will still be covered by Jackrabbit Classic.

3) However, there still are a few use cases where a client would like
to access data from more than one backend location, and having
separate Repository instances for such cases is a bit troublesome,
especially as Sling makes a fairly strong assumption of the system
having just a single Repository.

4) At Adobe we have proprietary "connector" code for accessing
external repositories and virtually "mounting" them within the main
repository. This functionality relies on the kind of limited workspace
support described above.

5) It would be useful in some cases to be able to store some content
for example in a TarMK backend and other in a MongoMK one, but still
access both backends through a single Repository. The proposed
workspace mechanism would make this possible with minimum impact on
existing code.

To do this, we'd need to extend the Jcr utility class to accept a
<String, NodeStore> map instead or as an alternative to just a single
NodeStore. And in an OSGi environment the NodeStore services would
become service factories that could produce any number of configured
NodeStore services, with the repository service tracking all the
available NodeStores and making them available as different
workspaces.

WDYT?

BR,

Jukka Zitting

Re: Workspaces, once more

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Wed, Feb 19, 2014 at 10:09 AM, Jukka Zitting <ju...@gmail.com> wrote:
> ...We won't support workspaces in the full JCR sense (shared jcr:system,
> cross-workspace operations, etc.). However, we do allow a repository
> to have more than one workspace, each workspace being it's own
> "mini-repository" with it's own user accounts, node types, version
> histories, etc...

Sounds good to me. Would that also allow for tuning various parts of
the content tree according to their usage, like for example saying
that /tmp and /var have no indexing, no versioning and no observation?
I haven't checked if other features of Oak allow that, but that would
be useful in large content repositories.

Each partition having its own user accounts is a bit worrying though,
won't that be an operations/admin problem? If you compare that with
unix filesystem partitions, all partitions share a common security
layer that's implemented on top of them.

-Bertrand