jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ste...@apache.org
Subject svn commit: r1081497 - /jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/MicroKernel.java
Date Mon, 14 Mar 2011 18:08:25 GMT
Author: stefan
Date: Mon Mar 14 18:08:24 2011
New Revision: 1081497

URL: http://svn.apache.org/viewvc?rev=1081497&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=1081497&r1=1081496&r2=1081497&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
Mon Mar 14 18:08:24 2011
@@ -19,12 +19,49 @@ package org.apache.jackrabbit.mk;
 import java.io.InputStream;
 
 /**
+ * The Repository <code>MicroKernel</code> design goals/principles:
+ * <ul>
+ * <li>manage huge trees of nodes and properties efficiently</li>
+ * <li>MVCC-based concurrency control</li>
+ * <li>GIT-inspired DAG-based (as opposed to delta-based) versioning model</li>
+ * <li>highly scalable concurrent read & write operations</li>
+ * <li>stateless API</li>
+ * <li>predefined timeout (e.g. 50ms) for reading methods</li>
+ * <li>portable to C</li>
+ * <li>efficient support for large number of child nodes</li>
+ * <li>integrated DataStore for storing/retrieving large binaries</li>
+ * </ul>
+ *
+ * The MicroKernel Data Model:
+ * <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
+ * of properties and an array of (child) node objects</li>
+ * <li>properties are represented as name/value pairs</li>
+ * <li>MVPs are represented as name/array-of-values pairs</li>
+ * <li>supported property types: string, number</li>
+ * <li>other property types (weak/hard reference, date, etc) would need to be
+ * encoded/mangled in name or value</li>
+ * <li>no support for JCR/XML-like namespaces, "foo:bar" is just an ordinary name</li>
+ * <li>properties and child nodes share the same namespace, i.e. a property and
+ * 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)
+ *
+ * Architecture (overview):
+ * <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>
+ * </ul>
+ *
  * TBD:
  *
  * - workspaces are just top-level nodes (e.g. /default. /system)
  *   => no need for inter-workspace operations, simplified versioning implementation
  *
- * - should the rmk support (polling) observation? are getHistory/diff good enough?
+ * - 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
@@ -36,25 +73,13 @@ import java.io.InputStream;
  *   uuid2nodeId index; alternatively jcr:uuid 'is' the nodeId -> no separate
  *   index required  => marker property? ":id"
  *
- * - should the rmk provide native support for shareable nodes?  => probably no
- *
- * - all reading methods have a predefined timeout (e.g. 50ms)
+ * - should the MicroKernel provide native support for shareable nodes?  => probably no
  *
  * JSON/JSOP:
  *
- * - json representation of properties:
- *   name/value pairs
- *   what about mvp? => array of vals
- *
- * - should child nodes and properties share the same namespace? => yes
- *
- * - does the order of child nodes matter? if yes, how should they be represented
- *   json (a json object is an unordered set of name/value pairs.
- *   => child nodes are represented as array
- *
  * - do we need to specify a 'reorder' op in jsop? perhaps based on 'move'?  => davex
- *
- * - how should an incomplete list of child nodes be represented in json? => length(array)
!= :childnodescount
+ * - 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
  */
 public interface MicroKernel {
 
@@ -77,13 +102,12 @@ public interface MicroKernel {
 
     // specialized methods for reading flat hierarchies
     String /* array of jsonTrees */ getChildNodes(String idOrPath, long offset, long count,
int depth, String revisionId) throws MicroKernelException;
-    // maybe represented as special property (":childnodecount") -> no need for specific
api method?
+    // maybe represented as special property (":childNodeCount") -> no need for specific
api method?
     long getChildNodeCount(String idOrPath, String revisionId) throws MicroKernelException;
 
     /**
      * WRITE ops
      */
-    /* @todo JSOP diff format doesn't specify a 'copy' op */
     String /* revisionId */ commit(String idOrPath, String jsonDiff) throws MicroKernelException;
 
     /**



Mime
View raw message