[ 
https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Guggisberg reopened OAK-162:
-----------------------------------


sorry, i  don't agree with the resolution.

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

Reply via email to