[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914576#comment-13914576
]
Marcel Reutegger commented on OAK-162:
--------------------------------------
bq. how would a remote jcr client (oak-jcr) access e.g. versioning
functionality provided by oak-core?
so far we didn't have this requirement, but in general it works by setting
protected properties on the Oak API level and a commit editor takes care of the
correct version related updates on the version storage. The contract is not
documented yet, but the general idea is described here:
http://markmail.org/message/k7bbvwvf25irn6jt
> 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)
