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:40:56 GMT
On Fri, Mar 9, 2012 at 2:15 PM, Angela Schreiber <anchela@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 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.

+1, i absolutely agree with angela.

cheers
stefan

> 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.
>
>
>> Before making the decision on this, here's a few questions to consider:
>>
>> 1) What's the main API through which functionality in oak-core (and
>> the potential low-level extensions it interacts with) shall be
>> accessed? Shall things like node type handling, versioning, locking
>> and query support be included in that API?
>
>
> my answer was that everything that needs validation for overall
> consistency and JCR compliance goes to the core (spi impl).
>
>
>> AFAIUI the MicroKernel
>> interface is intended more as an internal extension point and remoting
>> API instead of something that a client (including one like a specific
>> protocol binding) would directly interact with, so it probably
>> shouldn't be the API through which other components access
>> functionality in oak-core.
>
>
> i agree
>
>
>> 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.
>
>
>> 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.
>
> regards
> angela
>>
>> BR,
>>
>> Jukka Zitting

Mime
View raw message