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 Re: On setting component boundaries in Oak
Date Wed, 14 Mar 2012 18:43:03 GMT
Hi,

On Fri, Mar 9, 2012 at 2:46 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Makes sense to me too. So, to clarify the intended structure, I draw a
> quick draft of how our components could fit together:
>
>    http://people.apache.org/~jukka/2012/oak-overview.png

To expand on this a bit, here's more detailed diagram that attempts to
identify key APIs (green boxes) and main implementation components
(violet boxes):

    http://people.apache.org/~jukka/2012/oak-components.png

The API and protocol bindings on the top are just some examples. We
can have any number of such components working (simultaneously) on top
of an Oak repository.

The microkernel implementations at the bottom on the other hand are
exclusive. A given Oak repository instance uses only a single
microkernel implementation, though different repository instances can
obviously run on top of different microkernels.

The middle part of the diagram, ranging from the Oak API (using a
different term than "SPI" to avoid confusion with jr2) through the Oak
repository implementation to the underlying microkernel API, is in my
view the core part of Oak. It forms the core framework that's present
in all repository deployments, regardless of which bindings or other
clients are present and which microkernel implementation is used
below.

Since according to this overall architecture there's a 1-to-1
connection between these two APIs and the implementation in between
and since they together form the core of a repository instance, I
think we should (at least for now) keep them together the a single
"oak-core" component, as shown in this diagram:

    http://people.apache.org/~jukka/2012/oak-components2.png

The "oak-jcr" component that I also identified in the above diagram
would only contain the code needed to adapt between the Oak API and
the higher level JCR API.

BR,

Jukka Zitting

Mime
View raw message