Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4FFEB376.1070802@apache.org>
Date: Thu, 12 Jul 2012 12:22:30 +0100
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Internal content in Oak
References: 
 <CAOFYJNap8j6Sujz4Z--=CfnYDmuZWjE=y=zHKNOOUPkrAWmaZQ@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNap8j6Sujz4Z--=CfnYDmuZWjE=y=zHKNOOUPkrAWmaZQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 12.7.12 12: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.
>
> WDYT?

+1

I just discussed this with Thomas off line yesterday. We also need this 
for excluding the branch where the query index is saved from 
observation. Otherwise we'd create zillions of observation events for 
index updates.

Michael

>
> BR,
>
> Jukka Zitting
>