jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: On setting component boundaries in Oak
Date Fri, 09 Mar 2012 13:43:45 GMT
On 9.3.12 14:38, Stefan Guggisberg wrote:
> On Fri, Mar 9, 2012 at 2:30 PM, Michael Dürig<mduerig@apache.org>  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?


View raw message