21 messages in org.apache.jackrabbit.oak-devRe: Internal content in Oak| From | Sent On | Attachments |
|---|---|---|
| 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: | Angela Schreiber (anch...@adobe.com) | |
| Date: | Jul 17, 2012 4:01:26 am | |
| List: | org.apache.jackrabbit.oak-dev | |
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 angela
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.
WDYT?
BR,
Jukka Zitting