On 9.3.12 14:38, Stefan Guggisberg wrote:
On Fri, Mar 9, 2012 at 2:30 PM, Michael Dürig<[email protected]> wrote:
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 approaches, and the balance of the different solutions also
depends on the state of the overall architecture.
as far as i understand the overall strategy as presented by
david at the last f2f in basel the objective was to have a separate
API boundary (SPI-like).
therefore i would strongly suggest to separate jcr-transient
space from an "SPI" layer from the very beginning. based on
my experience both with jackrabbit-core and being the author
of the v1 SPI i am convinced that we should start with that
separation from the beginning and force ourselves to clearly
distinguish between the two.
we should start with an first proposal of what part of the
JCR implementation goes where and keep discussing those
decisions as we go ahead and face problems and inconsistencies.
I very much share these concerns. However, I'd rather wait a bit with
separating the two until we have the basic things in place. I think we
should add an extra bullet point for this on the release road map [1]:
* SPI extension model
I think 0.3 - May 2012 would be a good fit.
[1] http://markmail.org/thread/7dhxklytr2xaoe24
2) What kind of clients will interact directly with Oak through JCR
vs. some lover level API (call it Oak SPI for now)? For example, do we
want to build a WebDAV or JSON/JSOP protocol binding based directly on
the Oak SPI or should they work on top of the JCR binding like they
currently do in Jackrabbit 2.x? Using an appropriate lower level API
might make it easier or even possible to implement things like ETag
support for WebDAV.
as far as i understood from the discussions we had so far, we
have both use cases:
a) applications that interact with the JCR API
b) applications and non-java JCR implementations like the Jackalope
project that directly interact with the Oak SPI as you call it.
As far as I understood David, his take on this is that SPI is "everything
modulo transient space". So to take a more radical view: why not make the
SPI implement JCR but conceptually add a save operation right after each
transient operation?
why would that be useful?
Why do we need an SPI?
Michael
