Hi,
I agree that on the NodeStore level this is probably easy enough. However mind you that the JCR semantics demand for *a lot* of shared global state, all of which is implement on top of the NodeStore. It is this global state that complicated the composite store implementation and in fact required drastic limitations in some places.
If the segregation is security relevant we probably need to come up with similar limitations in order to properly sandbox the individual parts. E.g. don't leak through observation events, indexes, node type constraints leading to exceptions that could leak sensitive information. Avoid information exposure through the version store. Etc, etc...
Michael On 22.09.17 07:03, Tomek Rekawek wrote:
Hello Bertrand, this seems like an opposite of the composite node store - rather than combining multiple repositories together, we’re trying to split one repository into many jails. Maybe I’m too optimistic, but I think the implementation should be quite easy if done on the node store level. The node states / builders - the basic objects representing the data on the lowest abstraction level - don’t know anything about their parents and their paths. The API client just calls NodeStore#getRoot() and gets a node state representing the root. If we have the JailedNodeStore, it can go to the underlying segment- or document node store and return basically any node (eg. /jails/foo). The node store implementation have to take care of transforming it back to the right place when the client calls NodeStore#merge(). For instance, the structure for the SegmentMK repository is as follows: / /root /root/content /root/home /root/... /checkpoints/foo/root /checkpoints/bar/root Where the /root represents the actual repository root and the /checkpoints subtree represents the checkpoints and is not accessible directly. This shows how easy it is to return some part of the tree as the root and block the API client from accessing other parts laying higher. Regards, Tomek
