You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by "Stefan Guggisberg (JIRA)" <ji...@apache.org> on 2012/06/29 18:32:42 UTC
[jira] [Created] (OAK-162) Oak Layering / Remoting architecture
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