On Thu, Mar 15, 2012 at 9:07 AM, Angela Schreiber <anchela@adobe.com> wrote:
> 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.

agreed, and that's IMO good. we should allow for alternative
mk impls (like we did with the jr pm's) but we also should
also designate a default impl (sort of a mk api reference impl).

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

same here. the mk api should IMO be a separate individually
versioned maven project.

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

agreed, except that i would separate the mk api from the mk impls.

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

+1, otherwise untangling the components at a later stage would
be unnecessary hard.

cheers
stefan

>
> kind regards
> angela
>>
>> BR,
>>
>> Jukka Zitting