Hi, On Mon, Dec 3, 2012 at 5:17 PM, Marcel Reutegger <mreut...@adobe.com> wrote: >> or explicitly modify a version history > > why would you want to do that? I think it is better to limit the possible > modifications to what the spec allows you to do.
There are various potential scenarios where you might want to do something like that. For example when modifying a node type, it would be useful if I could also adjust all past versions of affected nodes to match the new type definition. Otherwise I wouldn't be able to check out those versions anymore. >> or a checked out node in ways that don't fit within >> the mentioned predefined operations. > > there wouldn't be any restrictions in this case. you can do whatever > you want with a checked out node. I probably missed something. > Can you describe in more detail what you mean here? One good example of a potential versioning operation that isn't covered by JCR 2.0 is rebase, i.e. adjusting the base version of a node without having to first restore that version and then re-apply all changes. It might be that we never need to support anything like that in practice, but I'd rather design the system so that we don't need to change the core implementation to support extensions like that. >> I wouldn't want to run into cases >> where a client can't do something it wants because doing so would >> trigger unwanted content modifications by the commit hooks. > > can you give an example? One potential use case would be a "partial checkin" where we want to create a new version with just a subset of the modified content in the checked out node (like you can easily do with svn or git). Can we do that without triggering a full checkin or checkpoint operation from a content hook? > yes, that would also work. though, it requires you to use those classes > on top of the oak-api when you want to provide remoting for version > operations. with my approach one could simply perform content > modifications on the oak api to trigger the version operations. A remoting layer can be made to expose also higher level operations above the Oak API. For example, if the versioning code was encapsulated in something like a VersioningOperations utility class the oak-http component could use it to provide direct HTTP access to such versioning oprations. A remote oak-jcr client could then use something like a VersioningOperationsOverHttp subclass to replace the direct Oak API code with higher-level alternatives. BR, Jukka Zitting
