Re: On setting component boundaries in Oak

2012-03-09 Thread Thomas Mueller
Hi, therefore i would strongly suggest to separate jcr-transient space from an SPI layer from the very beginning. Yes, I think we all agree on about the separation. What we not seem to agree is if separate packages is a good enough separation for now, or if it needs to be separate projects right

Re: On setting component boundaries in Oak

2012-03-09 Thread Stefan Guggisberg
On Fri, Mar 9, 2012 at 2:15 PM, Angela Schreiber anch...@adobe.com wrote: hi Following up on OAK-5, where the question came up on whether we should put the JCR binding for Oak to a separate oak-jcr component or just under an .oak.jcr package in oak-core. There are good arguments for both

svn commit: r1298833 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/model: ChildNodeEntry.java NodeState.java PropertyState.java

2012-03-09 Thread jukka
Author: jukka Date: Fri Mar 9 14:05:46 2012 New Revision: 1298833 URL: http://svn.apache.org/viewvc?rev=1298833view=rev Log: OAK-3: Internal tree model More specific documentation of the equality contract Modified:

Re: On setting component boundaries in Oak

2012-03-09 Thread Angela Schreiber
hi thomas therefore i would strongly suggest to separate jcr-transient space from an SPI layer from the very beginning. Yes, I think we all agree on about the separation. ok... that wasn't totally clear to me. I think multiple packages is good enough separation for now, while it doesn't

Re: On setting component boundaries in Oak

2012-03-09 Thread Thomas Mueller
Hi, Why do we need an SPI? My understanding is: so that non-Java clients such as PHP can access Oak/Jackrabbit. Plus, in case of Java, for remoting. I don't think non-Java clients will want to use JNI, so the remoting aspect is very important in my view (not necessarily urgent, but important).

Re: svn commit: r1298002 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/mk/store/StoredNodeAsState.java

2012-03-09 Thread Jukka Zitting
Hi, [s/dev@/oak-dev@/] On Thu, Mar 8, 2012 at 12:47 AM, Michael Dürig mdue...@apache.org wrote: Right. I should have read the Javadoc ;-) However, I'd make it more explicit there, that sub classes must not refine equality (i.e. take into account values of other fields). This will in almost

[jira] [Commented] (OAK-7) In-memory persistence

2012-03-09 Thread Stefan Guggisberg (Commented) (JIRA)
[ https://issues.apache.org/jira/browse/OAK-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226125#comment-13226125 ] Stefan Guggisberg commented on OAK-7: - Currently that's not possible since the

Interface for modifying trees

2012-03-09 Thread Jukka Zitting
Hi, When talking about the internal tree model before [1], we left it unspecified how such trees are created and modified. Currently that's done directly by the MicroKernel implementation talking with the lower level .mk.store.RevisionStore interface, but also here I think it would be useful to

[jira] [Commented] (OAK-7) In-memory persistence

2012-03-09 Thread Thomas Mueller (Commented) (JIRA)
[ https://issues.apache.org/jira/browse/OAK-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226164#comment-13226164 ] Thomas Mueller commented on OAK-7: -- By the way, the SimpleKernelImpl also runs fully in memory

Re: Interface for modifying trees

2012-03-09 Thread Thomas Mueller
Hi, I wonder whether it would be useful if the transient state can be accessed before creating a new NodeState, that is: interface NodeBuilder { String getProperty(String name); NodeState getChildNode(String name); } Regards, Thomas On 3/9/12 4:56 PM, Jukka Zitting