jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject On setting component boundaries in Oak
Date Fri, 09 Mar 2012 11:58:29 GMT
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