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 Thu, 15 Mar 2012 08:07:40 GMT
hi jukka

thanks for the summary

> 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

looks basically good

> The API and protocol bindings on the top are just some examples.

ok... because i am not so sure about a plain WebDAV binding.
imo that one would rather belong on top of the JCR binding.
so, i would rather not have listed here as long as we don't
really plan to build that as it might cause confusion.

> We can have any number of such components working (simultaneously) on top
> of an Oak repository.

agreed

> 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

that sounds reasonable.

> 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

well... but this means that the mk implementations that are
currently located in the oak-core module should be moved out
to some different component.

and if we do that i don't really like the idea of having the
MK-API being part of the oak-core module as it requires
MK-implementations to have a dependency to oak-core including
the API... that looks odd to me.

so, imo we should rather keep oak-api (aka spi) and the
mk api/impl separate. that would lead us to start with 3
components that identify the layers and make the dependencies
very clear.

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

makes sense. and again: oak-jcr needs to have a dependency
to the oak-api but should not deal with MK... having a clear
separation dependency-wise would be favorable here IMO.

kind regards
angela
> BR,
>
> Jukka Zitting

Mime
View raw message