Hi Jukka I like the idea.
Can the methods not supporting cross-partition operation be enumerated ? I would think it primarily concerns move. What about remove involving a partitioned subtree ? Regards Felix -- Typos caused by my iPhone > Am 19.02.2014 um 10:52 schrieb "Jukka Zitting" <jukka.zitt...@gmail.com>: > > 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 <jukka.zitt...@gmail.com> >> 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
