jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Internal content in Oak
Date Thu, 12 Jul 2012 11:18:44 GMT
On 2012-07-12 13:11, 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.
> ...

Sounds right to me; either a pattern as described above, or 
alternatively an *additional* extension namespace...

Best regard, Julian

View raw message