> On 27 Nov 2014, at 11:24, Michael Marth <[email protected]> wrote: > > Hi John, > > as Thomas mentioned, MK branches are an implementation detail of the micro > kernels that cannot (should not) be leveraged on higher level. > Your use case might be solvable by access control (so that authors 1 and 2 > see different parts of the tree). The query engine honours such ACLs so the > corresponding result sets would be different. > > In Adobe’s AEM6 the use case you describe has been solved on > application-level (i.e. above the JCR API) by creating a complete copy of the > tree under edit and merging back after edit (the merge happening on > application level again).
Is Oak smart enough to do copy on write? I discussed with Jukka a while back who said that architecturally Oak would also be capable to do provide the same model that TYPO3 provides. They provide a copy on write workspace cloning feature that makes it possible for users to clone workspaces, do their changes while seeing all changes done by the source workspace right away. These cloned workspaces basically just require storage for any changed node as unchanged nodes simply take the data from the source workspace (hence the ability to automatically see changes in the source workspace). At any rate, while architecturally possible, it of course would require a fair bit of work to implement this feature. But imho it would be a super awesome feature! regards, Lukas Kahwe Smith [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
