jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] [Created] (OAK-162) Oak Layering / Remoting architecture
Date Fri, 29 Jun 2012 16:32:42 GMT
Stefan Guggisberg created OAK-162:

             Summary: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message