hi jukka
thanks for the info.
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).
ok. i agree that it somewhat mixes levels, but that seems the be
a common problem with the current separation between oak-api and
the spi package (see below).
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.
one more comment regarding the exposure of NodeState: i realized that
the NodeState interface also makes it's way to the oak-API through
Root#getChangeExtractor. i create a new issue
https://issues.apache.org/jira/browse/OAK-191 to address this.
but i somewhat looks to be a basic problem (or misunderstanding) caused
the separation between oak-api and the spi.
just one additional example: the kind of permission evaluation i
envision for oak-core would to some extend need to read the access
control information from the content and evaluate if a given
Tree/NodeState or PropertyState was readable/writable taking all
the different types of content into account: regular, version content,
access control content, node type definitions and so forth...
in other words: the internal permission evaluation would need to
be aware of the nature of the individual content items. using
the Tree/PropertyState interface for that matter looks a bit
odd while at the same time the NodeState doesn't seem to be suitable either.
kind regards
angela
