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: | Jukka Zitting (jukk...@gmail.com) | |
| Date: | Jul 19, 2012 1:37:17 am | |
| List: | org.apache.jackrabbit.oak-dev | |
Hi,
On Thursday, July 19, 2012, Thomas Mueller wrote:
Š oak-http are the only complex direct Java clients of the Oak API
I thought Oak HTTP basically _is_ (very closely matches) the Oak API.
That's why I qualified it with "to a lesser degree", which you didn't include in your quote above.
On the other hand, we seem to have features (for example the transient space) that were originally planned for the client now implemented in Oak Core or even Oak MK (branch / merge). We should really discuss this.
See the list archives from around March and April for extensive
discussions about how the changelog of a transient space is best represented. The big point that people keep missing here is that we *need* a way to represent uncommitted changes inside oak-core, as otherwise things like node type validation or other commit hooks are impossible. A remoting client can and should still batch the transient space on the client side, the API design explicitly allows that.
BR,
Jukka Zitting
Thomas
On 7/18/12 4:17 PM, "Jukka Zitting" <jukk...@gmail.com<javascript:;>> wrote:
Hi,
On Tue, Jul 17, 2012 at 1:01 PM, Angela Schreiber
<anch...@adobe.com<javascript:;>
wrote:
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).
Right, it's a trade-off between the size of the Oak API and complexity of clients.
The reason why I instinctively prefer to keep the Oak API as tight and simple as possible is that we'll be needing various kinds of wrappers like remoting, caching, virtualization or logging layers around it. The smaller the API is, the easier it is to create and maintain such wrappers. And since oak-jcr and to a lesser degree oak-http are the only complex direct Java clients of the Oak API that we plan to support, pushing more functionality to above the Oak API to avoid complicating it is IMO often a reasonable tradeoff.
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?
In fact, the more I think of the specific case of the proposed ":childOrder" property and orderability of nodes, the more it seems that you are right - it is better to hide these details below the Oak API and explicitly extend the API with an orderBefore() method like the one in JCR. The main reason why I think we need to do this is access control - otherwise oak-core would in any case need to "understand" the :childOrder property in order to properly filter out the names of any child nodes that the current client doesn't have read access to and thus shouldn't be aware of.
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?
For now the only already existing cases are the :childOrder property needed by the orderability feature and the search index content that similarly needs to be hidden from clients of the Oak API for security reasons. Also in this case also the Oak API provides a mechanism for clients to properly access such internal content.
Potential other cases of such internal content could be locking details not exposed by mix:lockable, automatic node metadata (last modified, content hash, etc.), or conflict markers. Without looking deeper into how to implement such features it's hard to say how they'd be best handled.
BR,
Jukka Zitting
-- Jukka Zitting