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
