jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: On setting component boundaries in Oak
Date Fri, 09 Mar 2012 16:40:07 GMT
Hi,

Replying over all to this thread..

My take is, that we try to create such separate projects right from the start. Yes, I am already
thinking in Bundles. But having separate projects also makes it easier to really keep separate
things separate. I mean, it is impossible to polute some code with a dependency on another
package which exposes implementation details (see for example the NodeId parameters of Jackrabbit
2 PersistenceManager interface).

Yes it makes development a bit harder at the beginning -- but maintence will be a lot easier.

Also, if the package space is properly separated between the modules, it is much easier to
find the correct location of code. The problem with Jackrabbit 2 is, that this package space
is not properly separated and that some package expected in the one module is actually in
a different one (for example the jcr-server module hosting "webdav" packages which would be
expected in the webdav module).

And yes, I would create a MK API module separate from the Oak default MK implementation. As
I said elsewhere this helps other implementations as well as providing testcases to validate
MK implementations.

And yes, I would create a proper/separate Oak SPI, which is optimized for communication between
the transient space implementation part and the actual Oak implementation part. Again having
a separate Oak SPI module would help separating API from leaking implementation detail and
help build validation tests.

Regards
Felix 

Am 09.03.2012 um 03:58 schrieb Jukka Zitting:

> 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


Mime
View raw message