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 12:26:56 GMT


Given Jukka's considerations I think we should start out with two 
modules: one for the Microkernel and another for the JCR implementation 
on top of it.

Regarding the Microkernel: even though we consider this an "internal" 
interface at this point, the facts that we keep the interface language 
agnostic and want to use it as a remoting point clearly makes it a 
separate module.

Regarding the JCR implementation: Even though there most likely will be 
a further layering (oak-spi) in the future, I think the details are to 
vague still to make the split now. As Jukka mentioned, we should get a 
clearer picture on the use cases/clients for such the oak-spi before 
going forward here.


On 9.3.12 12:58, Jukka Zitting 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.
> 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? 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.
> 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.
> 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.
> BR,
> Jukka Zitting

View raw message