hi jukka
thanks for the summary
To expand on this a bit, here's more detailed diagram that attempts to
identify key APIs (green boxes) and main implementation components
(violet boxes):
http://people.apache.org/~jukka/2012/oak-components.png
looks basically good
The API and protocol
Hi,
On Thu, Mar 15, 2012 at 2:17 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Thu, Mar 15, 2012 at 1:57 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
Yep. I'd like to see that default MK be as simple as possible, ideally
just an in-memory implementation designed mostly for
Hi,
Alternatively, if we intend to have JCR as the only API through which
Oak repositories are accessed, then I completely agree with Thomas
that there's not much point in putting the JCR binding to a separate
component.
There is probably some misunderstanding... I didn't mean that the JCR
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
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
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
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).
