|Jukka Zitting||Jul 12, 2012 4:11 am|
|Julian Reschke||Jul 12, 2012 4:18 am|
|Michael Dürig||Jul 12, 2012 4:22 am|
|Thomas Mueller||Jul 12, 2012 4:44 am|
|Jukka Zitting||Jul 12, 2012 5:15 am|
|Angela Schreiber||Jul 17, 2012 4:01 am|
|Jukka Zitting||Jul 18, 2012 7:16 am|
|Thomas Mueller||Jul 19, 2012 12:21 am|
|Stefan Guggisberg||Jul 19, 2012 1:18 am|
|Jukka Zitting||Jul 19, 2012 1:37 am|
|Angela Schreiber||Jul 19, 2012 1:54 am|
|Jukka Zitting||Jul 19, 2012 1:57 am|
|Jukka Zitting||Jul 19, 2012 2:09 am|
|Thomas Mueller||Jul 19, 2012 2:25 am|
|Stefan Guggisberg||Jul 19, 2012 2:26 am|
|Thomas Mueller||Jul 19, 2012 2:29 am|
|Jukka Zitting||Jul 19, 2012 2:36 am|
|Angela Schreiber||Jul 19, 2012 2:59 am|
|Jukka Zitting||Jul 19, 2012 3:26 am|
|Alexander Klimetschek||Jul 19, 2012 11:58 am|
|Jukka Zitting||Jul 19, 2012 2:09 pm|
|Subject:||Re: Internal content in Oak|
|From:||Michael Dürig (mdue...@apache.org)|
|Date:||Jul 12, 2012 4:22:07 am|
On 12.7.12 12:11, Jukka Zitting wrote:
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.
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.