Novel workspace idea

[Jukka Zitting <ju...@gmail.com>]

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.

BR,

Jukka Zitting

Re: Novel workspace idea

[Lukas Kahwe Smith <sm...@pooteeweet.org>]

On Feb 14, 2013, at 8:27 , Jukka Zitting <ju...@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