hi jukka
i see your point regarding keeping the API as small as possible.
that's basically why i was asking for a list of those special
properties that we already know or envision to introduce.
was it possible for you to share the known set of special properties
with the team?
that would allow everyone involved to make up his/her
mind on whether it makes sense to expose them as regular items
or rather exposed them as part of the API. raising awareness of
the nature/necessity of that invisible content would also allow
to take additional point of views (e.g. access control) into
account. and maybe it doesn't make sense to treat them all the
same way.
kind regards
angela
On 7/18/12 4:17 PM, Jukka Zitting wrote:
Hi,
On Tue, Jul 17, 2012 at 1:01 PM, Angela Schreiber<[email protected]> wrote:
not sure if it wise to expose such invisible content as "regular items"
on the oak-api. somehow it looks problematic to me that oak-jcr needs to
deal with internal stuff (and thus any other implementation of the jcr-api
would need to do the same).
Right, it's a trade-off between the size of the Oak API and complexity
of clients.
The reason why I instinctively prefer to keep the Oak API as tight and
simple as possible is that we'll be needing various kinds of wrappers
like remoting, caching, virtualization or logging layers around it.
The smaller the API is, the easier it is to create and maintain such
wrappers. And since oak-jcr and to a lesser degree oak-http are the
only complex direct Java clients of the Oak API that we plan to
support, pushing more functionality to above the Oak API to avoid
complicating it is IMO often a reasonable tradeoff.
wasn't it a valid alternative to really keep the exact format of that
internal content as implementation detail in oak-core and rather expose
the information using specific methods on the oak-api/spi?
In fact, the more I think of the specific case of the proposed
":childOrder" property and orderability of nodes, the more it seems
that you are right - it is better to hide these details below the Oak
API and explicitly extend the API with an orderBefore() method like
the one in JCR. The main reason why I think we need to do this is
access control - otherwise oak-core would in any case need to
"understand" the :childOrder property in order to properly filter out
the names of any child nodes that the current client doesn't have read
access to and thus shouldn't be aware of.
having a comprehensive list of the affected internal content might be
helpful in order to decide on how to deal with it. do you know how
many different internal items we are taking about?
For now the only already existing cases are the :childOrder property
needed by the orderability feature and the search index content that
similarly needs to be hidden from clients of the Oak API for security
reasons. Also in this case also the Oak API provides a mechanism for
clients to properly access such internal content.
Potential other cases of such internal content could be locking
details not exposed by mix:lockable, automatic node metadata (last
modified, content hash, etc.), or conflict markers. Without looking
deeper into how to implement such features it's hard to say how they'd
be best handled.
BR,
Jukka Zitting
