Hi,
We discussed our options for (not) implementing workspace support a
few times in the past, but the outcome so far has been to postpone the
final decision and do just the minimum amount of work to keep all our
options open. As we now get closer to production-readiness, I think
it's time to
Hi,
In face-to-face discussion it came up that to avoid confusion, it
would make sense to use some other term than workspaces for the
proposed functionality. Also, we should extend the
JackrabbitRepository interface with some extra methods to make it
clear that the client isn't accessing a
Hi Jukka
I like the idea.
Can the methods not supporting cross-partition operation be enumerated ? I
would think it primarily concerns move.
What about remove involving a partitioned subtree ?
Regards
Felix
--
Typos caused by my iPhone
Am 19.02.2014 um 10:52 schrieb Jukka Zitting
Hi,
On Wed, Feb 19, 2014 at 10:09 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
...We won't support workspaces in the full JCR sense (shared jcr:system,
cross-workspace operations, etc.). However, we do allow a repository
to have more than one workspace, each workspace being it's own
Hi Jukka,
We are using jackrabbit / oak not in that way crx is using it.
Seeing workspaces as partitions can be ok .. for me it's only
a definition.
We are using workspaces as a separation of the whole repository
where each client have its place to store documents without
the opportunity to see
