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: Internal content in Oak
Date Tue, 17 Jul 2012 11:01:49 GMT
hi jukka

i commented on the issue but maybe it would have been better to
post it on the list (not sure....). here again:

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).

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?

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?

kind regards

On 7/12/12 1:11 PM, Jukka Zitting wrote:
> Hi,
> The discussion about orderable nodes (OAK-169) brought up a topic that
> we'll be needing in a few other cases as well: How to handle extra
> internal content that's needed to implement specific JCR features, but
> that generally shouldn't be directly visible through the JCR API?
> For example, the extra Oak-level property (or properties, depending on
> how we implement the feature) needed to keep track of JCR-level node
> ordering information needs to be available through the Oak API since
> oak-jcr needs it in order to correctly implement JCR methods like
> getNodes() or orderBefore(), but such extra properties shouldn't be
> directly visible to JCR clients as that would break application-level
> assumptions about node content and massively complicate node type
> handling.
> One approach that's been in the air so far is to use some built-in
> "oak" namespace for such internal, and then filter out all content
> under that namespace in the oak-jcr layer. However, I believe we'll
> need such a namespace also for things that *are* visible to clients.
> For example the proposed "oak:unstructured" node type (i.e.
> "nt:unstructured" without orderable child nodes or same name siblings)
> would need to be visible to JCR clients, and things like query index
> configuration (OAK-178) fall in to the same category. Also, using a
> "normal" JCR namespace introduces a potential conflict with existing
> namespace prefixes.
> So I was thinking of using an explicitly invalid JCR name pattern for
> such internal content. A nice one would be the ":name" pattern that's
> already used by the MicroKernel for the ":childNodeCount" and ":hash"
> pseudo-properties. For example, the child ordering information in
> OAK-169 could go to a ":childOrder" property that's visible through
> the Oak API and understood by things like namespace and node type
> validators. The oak-jcr component could then internally access and
> manipulate such properties, while automatically filtering them out
> from the set of content directly visible to the client.
> BR,
> Jukka Zitting

View raw message