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:30:48 GMT
>> 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?

>> 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.


View raw message