Hi, On Thu, Jul 19, 2012 at 10:40 AM, Angela Schreiber <[email protected]> wrote: > - what is the aim of the ReadOnlyTree?
As you noticed, it's meant for use by plugins that want to access a raw NodeState through the Tree API without any internal layers (security, etc.) in between. Ideally such a wrapper wouldn't be needed, as it mixes levels of abstraction, which is why I didn't want to spend too much time documenting it (I'm hoping to refactor it away later). > - is my assumption correct or would it be required to enforce access > restrictions on the ReadOnlyTree as well? You're correct. > - if the ReadOnlyTree is meant to be an 'internal' implementation of > the Tree interface, can we really enforce that it cannot be abused? Yes. As long as a client doesn't see the underlying NodeStates (or the MicroKernel), it can't do anything useful with ReadOnlyTree. > - i quickly checked if the NodeState interface was really just used > within oak-core and not exposed: however i found that there as least > one reference to the NodeState interface in oak-jcr (observation). That should probably move to a plugin in oak-core. BR, Jukka Zitting
