jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: On setting component boundaries in Oak
Date Fri, 09 Mar 2012 13:15:07 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.

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

> BR,
> Jukka Zitting

View raw message