jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: TreeImpl vs ReadOnlyTree
Date Thu, 19 Jul 2012 10:22:30 GMT
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

View raw message