jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Kahwe Smith <sm...@pooteeweet.org>
Subject Re: Novel workspace idea
Date Thu, 14 Feb 2013 21:47:46 GMT

On Feb 14, 2013, at 8:27 , Jukka Zitting <jukka.zitting@gmail.com> wrote:

> Hi,
> 
> When discussing workspaces and our options for implementing them, our
> main options so far have been:
> 
> 1) No workspace support (with jcr:system just a normal subtree)
> 2) Workspaces as fully independent trees (each with its own jcr:system)
> 3) Workspaces as subtrees of a bigger repository tree (with jcr:system
> mounted virtually to each workspace tree)
> 
> Working with the SegmentMK draft it occurred to me that we might also
> have another alternative:
> 
> 4) Workspaces as partial branches (with jcr:system as the only subtree
> synced across such workspace branches)
> 
> With such an approach each new workspace would start with a branched
> copy of the jcr:system subtree from the default workspace. That
> jcr:system branch would get periodically (or on-demand) synced to
> bring in new version histories and other repository-wide data like
> node types.
> 
> The benefit of such an approach would be to avoid the need for a
> virtual jcr:system subtree mount, making most operations in all
> workspaces behave like in option 1). The downsides are the added
> branching complexity, the MK support required for it and extra
> difficulty in ensuring things like consistent node type updates across
> all workspaces (since a Validator can only look at one branch at a
> time).
> 
> I'm bringing this up just as one more alternative to consider, not
> something that I think we definitely should implement. Personally I'd
> prefer to stick with options 1) or 2) until someone actually needs
> more feature-rich workspaces.

I think native workspace support is very useful especially if the intention is to bring jackrabbit
to a broader audience (especially hosters) which I think is a real possibility with PHPCR.

Some more semi related comments:
That being said, you might remember that I have asked before to support copy on write workspaces.
This is something that Midgard and TYPO3 support which makes it possible to give every admin
a dedicated workspace in which they can work on changes, while changes in the "main" repo
shine through. Midgard will go so far with this system that they will not even offer a save
button. all changes are auto saving and if an admin wants to undo, they simply pull it from
the "main" repo. if oak would support this mode, then this would likely dedicate more resources
for a migration to PHPCR. and honestly i really like this concept either way.

Another topic is I have found the ModeShape support for federation quite cool. Especially
the ability to mount a native file system as a subtree.

regards,
Lukas Kahwe Smith
smith@pooteeweet.org




Mime
View raw message