svn commit: r1082964 - /jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java

[st...@apache.org]

Author: stefan
Date: Fri Mar 18 16:32:12 2011
New Revision: 1082964

URL: http://svn.apache.org/viewvc?rev=1082964&view=rev
Log:
drafting a MicroKernel api (WIP)

Modified:
    jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java

Modified: jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java
URL: http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java?rev=1082964&r1=1082963&r2=1082964&view=diff
==============================================================================
--- jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java (original)
+++ jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java Fri Mar 18 16:32:12 2011
@@ -19,7 +19,7 @@ package org.apache.jackrabbit.mk;
 import java.io.InputStream;
 
 /**
- * The Repository <code>MicroKernel</code> design goals/principles:
+ * The MicroKernel <b>design goals/principles</b>:
  * <ul>
  * <li>manage huge trees of nodes and properties efficiently</li>
  * <li>MVCC-based concurrency control</li>
@@ -32,7 +32,7 @@ import java.io.InputStream;
  * <li>integrated DataStore for storing/retrieving large binaries</li>
  * </ul>
  *
- * The MicroKernel Data Model:
+ * The MicroKernel <b>Data Model</b>:
  * <ul>
  * <li>simple JSON-inspired data model: just nodes and properties</li>
  * <li>a node is represented as an object, consisting of an unordered collection
@@ -47,39 +47,42 @@ import java.io.InputStream;
  * a child node, sharing the same parent node, cannot have the same name</li>
  * </ul>
  *
- * @todo check DavEx protocol for potential overlap/input (e.g. JSON format)
+ * <b>Architecture (overview)</b>:
+ * <ol>
+ * <li>JCR (full TCK-compliant implementation)</li>
+ * <li>SPI (node types, workspaces, namespaces, access control, search, locking, ...)</li>
+ * <li><i>MicroKernel</i></li>
+ * </ol>
  *
- * Architecture (overview):
+ * <b>TBD</b>:
  * <ul>
- * <li>JCR (full TCK-compliant implementation)</li>
- * <li>SPI (node types, namespaces, access control, search, locking, ...)</li>
- * <li><b><i>MicroKernel</i></b></li>
+ * <li>The concept of JCR workspaces is decorated by the SPI layer as top-level nodes
+ *     in the MicroKernel (e.g. /default. /system); there's no need for
+ *     inter-workspace operations, allows simplified versioning implementation</li>
+ * <li>should the MicroKernel support (polling) observation?
+ *     => <code>getRevisions/getJournal</code> should be sufficient</li>
+ * <li>nodes are primarily accessed by path. node identifiers (nodeId) are
+ *     optional. if a new node is committed with a special marker property
+ *     (e.g. <code>":id" : null</code>), a system-generated unique identifier will be
+ *     assigned and exposed through the same <code>:id</code> property;
+ *     the MicroKernel maintains an id<->path index</li>
+ * <li><code>jcr:uuid</code> is decorated by the SPI on top of MicroKernel;
+ *     <code>jcr:uuid</code> is equivalent to the MicroKernel node identifier (<code>:id</code>)</li>
+ * <li>should the MicroKernel provide built-in support for shareable nodes?
+ *     => no (tentative)</li>
  * </ul>
  *
- * TBD:
- *
- * - workspaces are just top-level nodes (e.g. /default. /system)
- *   => no need for inter-workspace operations, simplified versioning implementation
- *
- * - should the MicroKernel support (polling) observation? are getHistory/diff good enough?
- *
- * - nodeId is unique per repository and system-generated (e.g. sha1 or similar)
- *   is the concept of a nodeId really required? if yes, how should the nodeId
- *   be exposed? as a system-generated synthetic property? should every node
- *   have a nodeId? if not, what governs the assignment of a nodeId?
- *   => marker property ":id": null, value will be assigned on node creation
- *
- * - jcr:uuid is a regular property, decorated on top of rmk, will require an external
- *   uuid2nodeId index; alternatively jcr:uuid 'is' the nodeId -> no separate
- *   index required  => marker property? ":id"
- *
- * - should the MicroKernel provide native support for shareable nodes?  => probably no
- *
- * JSON/JSOP:
+ * <b>JSON/JSOP</b>:
+ * <ul>
+ * <li>do we need to specify a 'reorder' op in jsop? perhaps based on 'move'?
+ *     => check full JSOP spec and davex</li>
+ * <li>do we need to specify a 'copy' op in jsop?
+ *     => check full JSOP spec and davex</li>
+ * <li>how should an incomplete list of child nodes be represented in json?
+ *     => length(array) != :childNodeCount</li>
+ * </ul>
  *
- * - do we need to specify a 'reorder' op in jsop? perhaps based on 'move'?  => davex
- * - do we need to specify a 'copy' op in jsop? => check full JSOP spec and davex
- * - how should an incomplete list of child nodes be represented in json? => length(array) != :childNodeCount
+ * @todo check DavEx protocol for potential overlap/input (e.g. JSON format)
  */
 public interface MicroKernel {