Hi, On Tue, Dec 4, 2012 at 2:02 PM, Marcel Reutegger <mreut...@adobe.com> wrote: > this implies that oak-jcr supports non-trivial node type modification. do > we really want to go there? to me this sounds like opening pandorra's > box :-/
No, oak-jcr doesn't need to support any such things. But it would be nice if the system allowed someone to implement something like that without having to tweak the internals. > I don't think this would require changes to the core implementation. > it would just be one more hook watching jcr:baseVersion. similar to > a restore the hook could allow modifications to jcr:baseVersion when > it is checked out and then perform the rebase. Yes, one could do that, but only if when you can adjust the set of hooks deployed with the repository. I'm hoping for a solution where a client that sees nothing but the external API would have as much freedom as possible within the bounds of access control and repository consistency. > you mean checkin a node, which has two modified properties, but we > only want to check in the change to one of the properties? hmm, no > that wouldn't be possible easily. but with JCR that's not possible either > and as the subject indicates, this is about JCR versioning ;) Right, but why limit our options, or more importantly the options of people who might want to extend Oak beyond JCR? > the major benefit I see with a commit hook based approach is > that we can seal off the version store and make it read-only. I think this > simplifies the process of mounting the version store into the workspace. I see the point, but I don't think you can make the version store read-only with this approach. How for example would you trigger operations like VersionHistory.addVersionLabel() or VersionHistory.removeVersion()? BR, Jukka Zitting
