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

        

Mime
View raw message