[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914713#comment-13914713
]
Michael Dürig commented on OAK-162:
-----------------------------------
bq. resolving the issue as 'not a problem', after almost 2 years of silence, is
IMO unacceptable.
There has been lots of discussions both on the list and on other issues and
thus sufficient opportunities to participate and shape the course and outcome
of Oak. The fact that there was silence on this particular issue does not
matter to that respect. It merely indicates that the scope of the issue was too
broad, too vague or was based on a wrong premise to be directly actionable upon
and that no one pursued it any further. As Jukka mentioned, the overall
architecture has evolved. That process has taken place in the open by the
consensus driven approach common to all Apache projects. Resolving this issue
now is a matter of hygiene while we progress towards our first major release.
> Oak Layering / Remoting architecture
> ------------------------------------
>
> Key: OAK-162
> URL: https://issues.apache.org/jira/browse/OAK-162
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: Stefan Guggisberg
>
> i had the impression that we started the oak project with a shared view of
> the layering architecture (roughly based on the jackrabbit spi
> abstraction/partitioning model).
> the jcr api already implies 2 layers (client/server):
> - session-related operations (transient space etc)
> -> javax.jcr.Session
> - workspace-related operations (versioning, locking, node types etc)
> -> javax.jcr.Workspace
> the jackrabbit spi represents the abstraction of the workspace-related
> functionality and obviously lends itself to be remoted.
> here's my understanding of how the oak layering model should look like:
> 1. jcr client (oak-jcr):
> exposes the jcr api and implements the session-related functionality
> (transient space!); delegates workspace-related operations to the
> spi (oak api)
> 2. server-side repository (oak-core): exposes the spi (oak api) and
> implements the workspace-related operations; delegates
> persistence-related operations to the mk (oak api)
> 3. persistence layer (oak-mk): exposes the mk api and implements
> persistence operations
> the oak api and the mk api are the obvious potential remoting points.
> i see the following issues with the current oak code base:
> - the 3 layers are not properly isolated, transient space operations
> e.g. reach through all 3 layers. workspace mgmt e.g. is
> handled on the client. if either the oak or the mk api is
> remoted this is serious potential performance problem.
> - there's a mismatch between the spi and the current oak api
> in terms of scope/functionality; several workspace operations
> (such as versioning, ns mgmt, node type mgmt) don't seem to
> be reflected in the oak api.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
