[
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13920794#comment-13920794
]
Michael Marth commented on OAK-162:
-----------------------------------
I agree that we should close this issue. I do not see how we could take any
action based on an description of an architecture that has evolved since the
issue was created.
[~stefan@jira], please provide a test case (preferably in a new issue) or a
description of the use case you have (on the list). This would allow the Oak
team to discuss your concerns on a more tangible level. Thanks!
> 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.2#6252)
