[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914582#comment-13914582
]
Jukka Zitting commented on OAK-162:
-----------------------------------
During those two years we had lots of discussions about these issues on
oak-dev@, and as a result I feel that this is no longer a problem, thus the
resolution. If not a problem, then at least incomplete, as I genuinely don't
know what you want changed and why.
bq. what remoting protocol?
The protocol you refer to in "if either the oak or the mk api is remoted", for
example oak-mk-remote.
bq. how would a remote jcr client (oak-jcr) access e.g. versioning
functionality provided by oak-core?
The way it already does. I don't see the problem here, can you elaborate?
> 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)
