Hello Robert & Michael, > On 22 Sep 2017, at 08:31, Robert Munteanu <romb...@apache.org> wrote: >> >> 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. > > But that would require support in the various Oak subsystems, like > indexing, node types, etc right? Either that, or we create full self- > contained 'jails' with node type definitions, indexes, principals, etc.
Yep, the idea I’ve described assumes that each jail is self-contained, with their own indexing data, users, etc. > On 22 Sep 2017, at 08:58, Michael Dürig <mdue...@apache.org> wrote: > 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… I think it’s an easier case than the composite node store, with the assumption as above (fully self-contained jails). With the composite node store we have to wrap the node state/builder objects, so their can be “switched” to appropriate mount on the right moment. For this jailed node store, we don’t need to wrap anything - we just return a node state /jail/foo as a root. Then it’s not possible to access any other part of the repository and jail has its own indexes, node types, version store, etc. With regards to the observation events, the jailed node store have to announce only the relevant part of the new state (so basically call newState.getChildNode(“jail/foo”)). Maybe my assumption that every jail is self-contained is too strong (and makes the multi-tenancy too expensive), but that was my idea coming from the initial Bertrand’s e-mail. Bertrand - could you clarify if the jails should share some data with the “main” repository (which would make it more difficult, as Robert and Michael wrote) or the self-contained approach is ok? Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com
