jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: On setting component boundaries in Oak
Date Fri, 09 Mar 2012 13:38:48 GMT
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?


>>> 3) Given that such an internal Oak SPI is needed above the MK level,
>>> are we confident enough that we know where that boundary between
>>> oak-core and the proposed oak-jcr components should be set and what
>>> the boundary should look like? Making a premature decision on that
>>> could easily become a self-fulfilling prophesy that binds us to a
>>> specific architectural layout. For example the current Jackrabbit SPI
>>> has some inherent design limitations that are very hard to fix anymore
>>> given that plenty of client code is already using it.
>> imo we should not be afraid of creating the boundary right from
>> the beginning and feeling free to adjust it as we go ahead.
>> but the prerequisite was to have a first draft of what goes where
>> that allows us to validate our assumptions and change or
>> refine them in the dev process.
> I'd also be fine with such an approach. But we need to make sure that we
> don't lock ourselves into backward compatibility liabilities right from the
> start.
> Michael

View raw message