Hi, In face-to-face discussion it came up that to avoid confusion, it would make sense to use some other term than "workspaces" for the proposed functionality. Also, we should extend the JackrabbitRepository interface with some extra methods to make it clear that the client isn't accessing a normal JCR workspace with the proposed feature.
Borrowing a term from operating systems, I propose that we'd call such standalone backend a repository "partition". Like on-disk partitions, each repository partition could have a completely separate configuration, and operations like moving stuff around that work within a single partition would not work across partition boundaries. BR, Jukka Zitting On Wed, Feb 19, 2014 at 4:09 AM, Jukka Zitting <[email protected]> wrote: > 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
