directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: rev 9972 - in incubator/directory/rms/trunk: . api api/xdocs gui gui/main/xdocs gui/xdocs jdbc jdbc/xdocs jdbm jdbm/xdocs je je/xdocs jndi jndi/xdocs spi spi/xdocs xdocs
Date Mon, 12 Apr 2004 16:39:30 GMT
Author: akarasulu
Date: Mon Apr 12 09:39:28 2004
New Revision: 9972

Modified:
   incubator/directory/rms/trunk/api/maven.xml
   incubator/directory/rms/trunk/api/xdocs/navigation.xml
   incubator/directory/rms/trunk/gui/main/xdocs/index.xml
   incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml
   incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml
   incubator/directory/rms/trunk/gui/main/xdocs/rt.xml
   incubator/directory/rms/trunk/gui/maven.xml
   incubator/directory/rms/trunk/gui/xdocs/index.xml
   incubator/directory/rms/trunk/gui/xdocs/navigation.xml
   incubator/directory/rms/trunk/gui/xdocs/ocmm.xml
   incubator/directory/rms/trunk/gui/xdocs/user-guide.xml
   incubator/directory/rms/trunk/jdbc/maven.xml
   incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml
   incubator/directory/rms/trunk/jdbm/maven.xml
   incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml
   incubator/directory/rms/trunk/je/maven.xml
   incubator/directory/rms/trunk/je/xdocs/index.xml
   incubator/directory/rms/trunk/je/xdocs/navigation.xml
   incubator/directory/rms/trunk/jndi/maven.xml
   incubator/directory/rms/trunk/jndi/xdocs/navigation.xml
   incubator/directory/rms/trunk/project.xml
   incubator/directory/rms/trunk/spi/maven.xml
   incubator/directory/rms/trunk/spi/xdocs/navigation.xml
   incubator/directory/rms/trunk/xdocs/navigation.xml
Log:
o made some site documentation fixes
o switched to referencing the correct RMS jira 
o corrected some build issues


Modified: incubator/directory/rms/trunk/api/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/api/maven.xml	(original)
+++ incubator/directory/rms/trunk/api/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/api">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/api">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/api/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/api/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/api/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
      <menu name="Resources">
          <item name="IRC" href="../../../irc.html"/>
-         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
          <item name="Wiki" href="http://wiki.apache.org/directory"/>
          <item name="Lists" href="../../../mailing-lists.html"/>
          <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/gui/main/xdocs/index.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/index.xml	(original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/index.xml	Mon Apr 12 09:39:28 2004
@@ -1,21 +1,21 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
-  <body>
-    <properties>
-      <author email="akarasulu@apache.org">Alex Karasulu</author>
-      <title>RMS Management Console (RMC)</title>
-    </properties>
-    
-    <section name="RMS Management Console">
-      <p>
-        Welcome to the RMS Management Console Home Page!
-      </p>
-      <p>
-        The RMS Management Console or RMC is used to manage the entities within
-        a realm.  Applications, users, profiles, permissions, roles et. cetera.
-        are managed by environment operators using this console application 
-        which directly alters the authoritative RMS datastore.
-      </p>
-    </section>
-  </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <body>
+    <properties>
+      <author email="akarasulu@apache.org">Alex Karasulu</author>
+      <title>RMS Management Console (RMC)</title>
+    </properties>
+    
+    <section name="RMS Management Console">
+      <p>
+        Welcome to the RMS Management Console Home Page!
+      </p>
+      <p>
+        The RMS Management Console or RMC is used to manage the entities within
+        a realm.  Applications, users, profiles, permissions, roles et. cetera.
+        are managed by environment operators using this console application 
+        which directly alters the authoritative RMS datastore.
+      </p>
+    </section>
+  </body>
 </document>

Modified: incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -1,15 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project>
-  <title>RMS Management Console (RMC)</title>
-  <body>
-    <links>
-      <item name="RMS" href="http://openrms.sourceforge.net"/>
-      <item name="RMS" href="http://openrms.sourceforge.net"/>
-    </links>
-    
-    <menu name="About RMC">
-      <item name="Requirements" href="requirements.html"/>
-      <item name="Random Thoughts" href="requirements.html"/>
-    </menu>
-  </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<project>
+  <title>RMS Management Console (RMC)</title>
+  <body>
+    <links>
+      <item name="RMS" href="http://openrms.sourceforge.net"/>
+      <item name="RMS" href="http://openrms.sourceforge.net"/>
+    </links>
+    
+    <menu name="About RMC">
+      <item name="Requirements" href="requirements.html"/>
+      <item name="Random Thoughts" href="requirements.html"/>
+    </menu>
+  </body>
 </project>

Modified: incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml	(original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/requirements.xml	Mon Apr 12 09:39:28 2004
@@ -1,209 +1,209 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
-  <body>
-    <properties>
-      <author email="akarasulu@apache.org">Alex Karasulu</author>
-      <title>Rms Management Console Requirements</title>
-    </properties>
-    
-    <section name="Rms Management Console Requirements">
-      <subsection name="UI Description">
-        <p>
-          The UI will be designed to resemble the Microsoft Management Console 
-          (MMC) application.  Snap-ins for the Rms console like MMC snap-ins
-          will have other snap-ins associated with them heirarchically.  The
-          snap-ins and their heirarchy will be displayed like the MMC in a tree
-          on the left hand side of a split pane.
-        </p>
-        
-        <p>
-          On the right hand side of the split pane plugins can display within a
-          table any information they would like.  Basically selecting a plugin
-          node in the tree hands over control of this area to the right to that
-          plugin.  The plugin may populate the table with what ever content it
-          needs as well as change the popup menus triggered on the cells of the
-          table.
-        </p>
-        
-        <p>
-          On the tree display when expanding a plugin it is upto the plugin to
-          return the set of child plugins to display.  Each subordinate plugin
-          when selected displays rows in the table to the right of the split 
-          pan in accordance with the context of the plugin.  Here's what the 
-          MMC looks like to show the kind of UI we are talking about:
-        </p>
-        <center><img src="images/mmc.png"/></center>
-      </subsection>
-      <subsection name="Design Aspects">
-        <p>
-          A main application is required as a baseline where plugins can be 
-          snapped in.  The main UI and the plugins should all be IoC enabled
-          components.  There will be initially two plugins: one to manage users
-          and another to manage applications.
-        </p>
-        
-        <p>
-          Let's explore the application plugin.  This plugin when selected 
-          will list the set of applications in the system within the 
-          table to the right hand side.  If the plugin's node in the tree on the
-          left hand side is expanded then all the applications are displayed in
-          the tree.  When application nodes are selected they display two 
-          containers: one for roles and another for permissions.  When expanded
-          the application node displays these two child nodes.  When these nodes
-          are selected the set or roles or permissions respectively are listed
-          within the table to the right.  Also when expanded these nodes display
-          the roles or permissions respectively within the tree on the left.  
-        </p>
-        
-        <p>
-          The user plugin will enable the management of users and user 
-          application authorization profiles.  The plugin when expanded in the
-          tree will list the set of users.  When selected the table to the right
-          will display these users as rows in the table.  Users when expanded
-          will display profiles for various applications in the system.  Each
-          profile will then display containers for the roles, grants and denials
-          of permissions in the associated application for that profile.
-        </p>
-      </subsection>
-    </section>
-    <section name="Random Thoughts On Tree Based Navigation">
-      <p>
-        The main console application will need to expose access to its tree
-        and table realestate.  I have no idea on how this could be done right
-        now.  Perhaps its best to explore what a standard UI design would 
-        entail and then refactor that to use plugins. That's probably the 
-        best approach to weed out the better plugin based design.
-      </p>
-
-      <subsection name="Navigation Based on Database Metadata">
-        <p>
-          We need to build a tree model based on the contents of the database.
-          Basically clicking on an application's roles tree node should list
-          the roles in the application.  We have a drill down mechanism with
-          the tree to explore RMS contents.  Not every node in the tree can be
-          logically inferred or can it?  Take for example the containers of 
-          objects like roles and permissions - can we infer the need to create
-          the container for these objects that are of zero to many cardinality
-          in relation to the application?  They really can be but its a PITA to 
-          do this with reflection or reading the database's meta data to devise
-          a generic navigation just for this small set of object types.  
-        </p>
-        
-        <p>
-          For the heck of it let's just explore the idea of building a tree 
-          navigator that uses database metadata.  Such a navigator must be given
-          a set of seed tables.  These seed tables are the child nodes right 
-          under the root of the tree.  The metadata is used to determine the 
-          tables that have a foreign key to the seed table.  For simplicity, let
-          us automatically presume the cardinality of the fk relation to always 
-          be zero or more.  This way every child table with a fk automatically 
-          represents a container node under the parent table.  This container 
-          node will contain the records of the child table within it.  The fk 
-          relations to the children will also be evaluated to determine their 
-          child containers as well.
-        </p>
-        
-        <p>
-          This sounding pretty cool now.  Let's step through the events of 
-          exploring the application seed node.  The application node is 
-          represented as a container with the label 'applications'.  Expanding
-          this branch node lists all the applications by name under it.  These
-          applications can in turn be expanded to display two child containers
-          labeled, 'roles' and 'permissions'.  Expanding the permissions 
-          container would list the set of permissions associated with the 
-          application.  The permissions themselves are terminal and cannot be
-          expanded.  Expansion of the roles container displays the roles of the
-          user.  Now each role is referenced by a user profile but we do not
-          want to display the user profile under each role or do we?  Also roles
-          have grants but these grants are a hunk of binary data that cannot be
-          displayed appropriately using this scheme based on database metadata.
-          A special editor is required to display the actual list of grants 
-          rather than this blob of binary data.  These are the areas that are
-          gray with respect to this technique.
-        </p>
-        
-        <p>
-          Furthermore we need a way to determine how to name container nodes and
-          the labels of the records they use.  A mapping is required to 
-          associate a container label for a table and a container child node 
-          label for each row in that table.  The container label is easy.  The 
-          container label map just says for table 'FOO', name the container 
-          'Foos' and if there is an 'S' or 's' at the end of the table name then
-          don't add the extra 's' for the container name.  Now the child nodes
-          in the container can be named using a map that specifies the column 
-          value to use as the container's unique name for the child node.  So 
-          for a role the ROLE_NAME column could be used.  In this case the value
-          for the ROLE_NAME would be used to name the child node in the roles 
-          container.
-        </p>
-      </subsection>
-      <subsection name="Navigation Based on Object Model Metadata">
-        <p>
-          This database metadata based navigation takes us to the records of 
-          interest.  But keep in mind we really should not be dealing with 
-          database records or constructs at this point.  We should be using the
-          value objects created from the database.
-        </p>
-        <p>
-          So then where does this leave us.  Well we now have to deal with 
-          reflection to understand the containment heirarchy.  The metadata 
-          we're looking for is now based on class and interface information 
-          which we use reflection to get to.  This may actually be better for us
-          because it reduces some of the complications of the database metadata 
-          based navigation above.  For example the issue of flowing over into 
-          profiles because of a fk to the APP_ROLES table from the 
-          USER_APP_PROFILE_ROLES table is no longer there.  The Role interface 
-          does not allow access to the profiles that reference the Role.  Also 
-          the Role grants which are efficiently stored in the database as binary
-          data no longer represent scaler quantities.  They become containers 
-          that can reveal the set of permissions granted to the role or those 
-          that are associated with the role.  So we actually gain more from the 
-          padding that reflection on interfaces gives us when building such a 
-          navigation system.
-        </p>
-        
-        <p>
-          There are however some problems that will result.  The relationships
-          between objects are often not so clear when container classes are 
-          used to return objects rather than using arrays of those class 
-          instances.  Take for example return types using an Iterator.  The
-          type of the underlying objects returned is lost.  We have to infer
-          the type based on some naming convention or provide some extra meta
-          information.
-        </p>
-        
-        <p>
-          Let's conduct the same exercise using reflection for navigation rather
-          than using database metadata.  Again some seed information is 
-          required for the first teir of child nodes under the root of the tree.
-          When using database metadata the seeds were table names, which allowed
-          the lookup of records in those tables when the container for the table
-          was expanded.  The seeds for reflection require a class or interface
-          name as well as a factory like object for listing the set of objects 
-          that implement that interface.  The RMS top level facade will be that
-          factory but I don't think we should use that.  Instead a new set of
-          factories should be created to return these objects.  Even for objects
-          that are returned by the parent we should expose these 'factories'.
-          Perhaps a 'factory' is not a good term for these objects that help
-          operate on the containment trees of other objects.  These peer 
-          factories or what ever could also provide extra hints and meta data 
-          not easily inferred through reflection regarding the composition of 
-          the class the factory is dedicated to.  Basically the factory can 
-          either describe or clarify which functions to use to acquire child 
-          objects or a listing for them so reflection can proceed.  The factory 
-          can also provide other things like menus and editors for child 
-          elements and so on.
-        </p>
-        
-        <p>
-          This route is sounding much better now.  There is a well defined node 
-          type helper or container class defined (the helper factory thingy we
-          talked about above).  An instance of this class is registered for each
-          data type involved in the containment hierary.  Any objects that do
-          not have registered helper containers for their classes or interfaces
-          are deamed scalar objects and are not expandable as container objects.
-        </p>
-      </subsection>
-    </section>
-  </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <body>
+    <properties>
+      <author email="akarasulu@apache.org">Alex Karasulu</author>
+      <title>Rms Management Console Requirements</title>
+    </properties>
+    
+    <section name="Rms Management Console Requirements">
+      <subsection name="UI Description">
+        <p>
+          The UI will be designed to resemble the Microsoft Management Console 
+          (MMC) application.  Snap-ins for the Rms console like MMC snap-ins
+          will have other snap-ins associated with them heirarchically.  The
+          snap-ins and their heirarchy will be displayed like the MMC in a tree
+          on the left hand side of a split pane.
+        </p>
+        
+        <p>
+          On the right hand side of the split pane plugins can display within a
+          table any information they would like.  Basically selecting a plugin
+          node in the tree hands over control of this area to the right to that
+          plugin.  The plugin may populate the table with what ever content it
+          needs as well as change the popup menus triggered on the cells of the
+          table.
+        </p>
+        
+        <p>
+          On the tree display when expanding a plugin it is upto the plugin to
+          return the set of child plugins to display.  Each subordinate plugin
+          when selected displays rows in the table to the right of the split 
+          pan in accordance with the context of the plugin.  Here's what the 
+          MMC looks like to show the kind of UI we are talking about:
+        </p>
+        <center><img src="images/mmc.png"/></center>
+      </subsection>
+      <subsection name="Design Aspects">
+        <p>
+          A main application is required as a baseline where plugins can be 
+          snapped in.  The main UI and the plugins should all be IoC enabled
+          components.  There will be initially two plugins: one to manage users
+          and another to manage applications.
+        </p>
+        
+        <p>
+          Let's explore the application plugin.  This plugin when selected 
+          will list the set of applications in the system within the 
+          table to the right hand side.  If the plugin's node in the tree on the
+          left hand side is expanded then all the applications are displayed in
+          the tree.  When application nodes are selected they display two 
+          containers: one for roles and another for permissions.  When expanded
+          the application node displays these two child nodes.  When these nodes
+          are selected the set or roles or permissions respectively are listed
+          within the table to the right.  Also when expanded these nodes display
+          the roles or permissions respectively within the tree on the left.  
+        </p>
+        
+        <p>
+          The user plugin will enable the management of users and user 
+          application authorization profiles.  The plugin when expanded in the
+          tree will list the set of users.  When selected the table to the right
+          will display these users as rows in the table.  Users when expanded
+          will display profiles for various applications in the system.  Each
+          profile will then display containers for the roles, grants and denials
+          of permissions in the associated application for that profile.
+        </p>
+      </subsection>
+    </section>
+    <section name="Random Thoughts On Tree Based Navigation">
+      <p>
+        The main console application will need to expose access to its tree
+        and table realestate.  I have no idea on how this could be done right
+        now.  Perhaps its best to explore what a standard UI design would 
+        entail and then refactor that to use plugins. That's probably the 
+        best approach to weed out the better plugin based design.
+      </p>
+
+      <subsection name="Navigation Based on Database Metadata">
+        <p>
+          We need to build a tree model based on the contents of the database.
+          Basically clicking on an application's roles tree node should list
+          the roles in the application.  We have a drill down mechanism with
+          the tree to explore RMS contents.  Not every node in the tree can be
+          logically inferred or can it?  Take for example the containers of 
+          objects like roles and permissions - can we infer the need to create
+          the container for these objects that are of zero to many cardinality
+          in relation to the application?  They really can be but its a PITA to 
+          do this with reflection or reading the database's meta data to devise
+          a generic navigation just for this small set of object types.  
+        </p>
+        
+        <p>
+          For the heck of it let's just explore the idea of building a tree 
+          navigator that uses database metadata.  Such a navigator must be given
+          a set of seed tables.  These seed tables are the child nodes right 
+          under the root of the tree.  The metadata is used to determine the 
+          tables that have a foreign key to the seed table.  For simplicity, let
+          us automatically presume the cardinality of the fk relation to always 
+          be zero or more.  This way every child table with a fk automatically 
+          represents a container node under the parent table.  This container 
+          node will contain the records of the child table within it.  The fk 
+          relations to the children will also be evaluated to determine their 
+          child containers as well.
+        </p>
+        
+        <p>
+          This sounding pretty cool now.  Let's step through the events of 
+          exploring the application seed node.  The application node is 
+          represented as a container with the label 'applications'.  Expanding
+          this branch node lists all the applications by name under it.  These
+          applications can in turn be expanded to display two child containers
+          labeled, 'roles' and 'permissions'.  Expanding the permissions 
+          container would list the set of permissions associated with the 
+          application.  The permissions themselves are terminal and cannot be
+          expanded.  Expansion of the roles container displays the roles of the
+          user.  Now each role is referenced by a user profile but we do not
+          want to display the user profile under each role or do we?  Also roles
+          have grants but these grants are a hunk of binary data that cannot be
+          displayed appropriately using this scheme based on database metadata.
+          A special editor is required to display the actual list of grants 
+          rather than this blob of binary data.  These are the areas that are
+          gray with respect to this technique.
+        </p>
+        
+        <p>
+          Furthermore we need a way to determine how to name container nodes and
+          the labels of the records they use.  A mapping is required to 
+          associate a container label for a table and a container child node 
+          label for each row in that table.  The container label is easy.  The 
+          container label map just says for table 'FOO', name the container 
+          'Foos' and if there is an 'S' or 's' at the end of the table name then
+          don't add the extra 's' for the container name.  Now the child nodes
+          in the container can be named using a map that specifies the column 
+          value to use as the container's unique name for the child node.  So 
+          for a role the ROLE_NAME column could be used.  In this case the value
+          for the ROLE_NAME would be used to name the child node in the roles 
+          container.
+        </p>
+      </subsection>
+      <subsection name="Navigation Based on Object Model Metadata">
+        <p>
+          This database metadata based navigation takes us to the records of 
+          interest.  But keep in mind we really should not be dealing with 
+          database records or constructs at this point.  We should be using the
+          value objects created from the database.
+        </p>
+        <p>
+          So then where does this leave us.  Well we now have to deal with 
+          reflection to understand the containment heirarchy.  The metadata 
+          we're looking for is now based on class and interface information 
+          which we use reflection to get to.  This may actually be better for us
+          because it reduces some of the complications of the database metadata 
+          based navigation above.  For example the issue of flowing over into 
+          profiles because of a fk to the APP_ROLES table from the 
+          USER_APP_PROFILE_ROLES table is no longer there.  The Role interface 
+          does not allow access to the profiles that reference the Role.  Also 
+          the Role grants which are efficiently stored in the database as binary
+          data no longer represent scaler quantities.  They become containers 
+          that can reveal the set of permissions granted to the role or those 
+          that are associated with the role.  So we actually gain more from the 
+          padding that reflection on interfaces gives us when building such a 
+          navigation system.
+        </p>
+        
+        <p>
+          There are however some problems that will result.  The relationships
+          between objects are often not so clear when container classes are 
+          used to return objects rather than using arrays of those class 
+          instances.  Take for example return types using an Iterator.  The
+          type of the underlying objects returned is lost.  We have to infer
+          the type based on some naming convention or provide some extra meta
+          information.
+        </p>
+        
+        <p>
+          Let's conduct the same exercise using reflection for navigation rather
+          than using database metadata.  Again some seed information is 
+          required for the first teir of child nodes under the root of the tree.
+          When using database metadata the seeds were table names, which allowed
+          the lookup of records in those tables when the container for the table
+          was expanded.  The seeds for reflection require a class or interface
+          name as well as a factory like object for listing the set of objects 
+          that implement that interface.  The RMS top level facade will be that
+          factory but I don't think we should use that.  Instead a new set of
+          factories should be created to return these objects.  Even for objects
+          that are returned by the parent we should expose these 'factories'.
+          Perhaps a 'factory' is not a good term for these objects that help
+          operate on the containment trees of other objects.  These peer 
+          factories or what ever could also provide extra hints and meta data 
+          not easily inferred through reflection regarding the composition of 
+          the class the factory is dedicated to.  Basically the factory can 
+          either describe or clarify which functions to use to acquire child 
+          objects or a listing for them so reflection can proceed.  The factory 
+          can also provide other things like menus and editors for child 
+          elements and so on.
+        </p>
+        
+        <p>
+          This route is sounding much better now.  There is a well defined node 
+          type helper or container class defined (the helper factory thingy we
+          talked about above).  An instance of this class is registered for each
+          data type involved in the containment hierary.  Any objects that do
+          not have registered helper containers for their classes or interfaces
+          are deamed scalar objects and are not expandable as container objects.
+        </p>
+      </subsection>
+    </section>
+  </body>
 </document>

Modified: incubator/directory/rms/trunk/gui/main/xdocs/rt.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/main/xdocs/rt.xml	(original)
+++ incubator/directory/rms/trunk/gui/main/xdocs/rt.xml	Mon Apr 12 09:39:28 2004
@@ -22,11 +22,11 @@
         </li>
         <li>
           Brute force code will be faster to write and I can start taking notes 
-          as ideas come up about where to take the design.
+          as ideas come up about where to take the design.
         </li>
         <li>
-          Can always refactor!
-        </li>
+          Can always refactor!
+        </li>
       </ul>
      </subsection>
      

Modified: incubator/directory/rms/trunk/gui/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/maven.xml	(original)
+++ incubator/directory/rms/trunk/gui/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/admin">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/admin">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/gui/xdocs/index.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/index.xml	(original)
+++ incubator/directory/rms/trunk/gui/xdocs/index.xml	Mon Apr 12 09:39:28 2004
@@ -16,7 +16,7 @@
       <p>
         RMC has already been built and documenation on it will be made 
         available soon.  Hang tight and take a look at the UI snapshots 
-        <a href="./snapshots.html">here</a>.
+        <a href="./snapshots.html">here</a>.
       </p>
     </section>
     
@@ -29,7 +29,7 @@
         <tr><th>Topic</th><th>Description</th></tr>
         <tr>
           <td><a href="./RMSAdminConsoleAndPlugins.doc">RMC Design</a></td>
-          <td>Detailed design document on the RMS Management Console</td>
+          <td>Detailed design document on the RMS Management Console</td>
         </tr>
         <tr>
           <td><a href="./ocmm.html">RMC OCMM</a></td>
@@ -37,15 +37,15 @@
             The UI uses a special Object Containment Meta Model (OCMM) to 
             navigate the objects within the database and allow users of the 
             RMC to alter them.  This section discusses the OCMM.
-          </td>
+          </td>
         </tr>
         <tr>
           <td><a href="./user-guide.html">RMC User Guide</a></td>
           <td>
-            Describes how to effectively use the RMS Management Console.
-          </td>
-        </tr>
-      </table>
+            Describes how to effectively use the RMS Management Console.
+          </td>
+        </tr>
+      </table>
     </section>
   </body>
 </document>

Modified: incubator/directory/rms/trunk/gui/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/gui/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -35,7 +35,7 @@
 
      <menu name="Resources">
          <item name="IRC" href="../../../irc.html"/>
-         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
          <item name="Wiki" href="http://wiki.apache.org/directory"/>
          <item name="Lists" href="../../../mailing-lists.html"/>
          <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/gui/xdocs/ocmm.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/ocmm.xml	(original)
+++ incubator/directory/rms/trunk/gui/xdocs/ocmm.xml	Mon Apr 12 09:39:28 2004
@@ -1,15 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
-  <properties>
-    <author email="akarasulu@apache.org">Alex Karasulu</author>
-    <title>RMS Management Console: Object Containment Meta Model</title>
-  </properties>
-  <body>
-    
-    <section name="Object Containment Meta Model (OCMM)">
-      <p>
-        Coming soon ...
-      </p>
-    </section>
-  </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>RMS Management Console: Object Containment Meta Model</title>
+  </properties>
+  <body>
+    
+    <section name="Object Containment Meta Model (OCMM)">
+      <p>
+        Coming soon ...
+      </p>
+    </section>
+  </body>
 </document>

Modified: incubator/directory/rms/trunk/gui/xdocs/user-guide.xml
==============================================================================
--- incubator/directory/rms/trunk/gui/xdocs/user-guide.xml	(original)
+++ incubator/directory/rms/trunk/gui/xdocs/user-guide.xml	Mon Apr 12 09:39:28 2004
@@ -1,15 +1,15 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
-  <properties>
-    <author email="akarasulu@apache.org">Alex Karasulu</author>
-    <title>RMS Management Console: User Guide</title>
-  </properties>
-  <body>
-    
-    <section name="RMC User Guide">
-      <p>
-        Coming soon ...
-      </p>
-    </section>
-  </body>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>RMS Management Console: User Guide</title>
+  </properties>
+  <body>
+    
+    <section name="RMC User Guide">
+      <p>
+        Coming soon ...
+      </p>
+    </section>
+  </body>
 </document>

Modified: incubator/directory/rms/trunk/jdbc/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbc/maven.xml	(original)
+++ incubator/directory/rms/trunk/jdbc/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/jdbc">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/jdbc">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/jdbc/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
      <menu name="Resources">
          <item name="IRC" href="../../../irc.html"/>
-         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
          <item name="Wiki" href="http://wiki.apache.org/directory"/>
          <item name="Lists" href="../../../mailing-lists.html"/>
          <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/jdbm/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbm/maven.xml	(original)
+++ incubator/directory/rms/trunk/jdbm/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/jdbm">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/jdbm">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/jdbm/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
     <menu name="Resources">
       <item name="IRC" href="../../../irc.html"/>
-      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>
       <item name="Lists" href="../../../mailing-lists.html"/>
       <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/je/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/je/maven.xml	(original)
+++ incubator/directory/rms/trunk/je/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/je">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/je">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/je/xdocs/index.xml
==============================================================================
--- incubator/directory/rms/trunk/je/xdocs/index.xml	(original)
+++ incubator/directory/rms/trunk/je/xdocs/index.xml	Mon Apr 12 09:39:28 2004
@@ -1,114 +1,114 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
-  <properties>
-    <author email="akarasulu@apache.org">Alex Karasulu</author>
-    <title>RMS JE Provider</title>
-  </properties>
-  <body>
-
-    <section name="Justification">
-      <p>
-        RMS requires a simple yet fast database where the relationships
-        between entities are known in advance.  The database may be large
-        in terms of the number entries per data type however the size of
-        the data in bytes will be small.
-      </p>
-
-      <p>
-        These requirements lead us to believe that the most optimal
-        configuration for an RMS implementation is a custom database
-        based on a btree implementation.  Such an implementation would
-        store data within B-Trees and associate keys programatically
-        to establish relationships between entities.
-      </p>
-
-      <p>
-        Searches would be extremely fast without the need for an interpreter
-        and access would be in constant time regardless of the size of the
-        database.  Access to a local database file is required for such an
-        implementation, hence some form of replication must exist to update
-        the contents of files when changes occur to the master RMS store.
-        The additional replication requirement occurs for all implementations
-        and is not a big concern since the data set is small and the frequency
-        of mutation is even smaller.
-      </p>
-      
-      <p>
-        JE is SleepCat's Java BTree implementation.  Building an RMS provider
-        based on JE is the target of this subproject.
-      </p>
-    </section>
-
-
-    <section name="Design">
-      <p>
-        It would be most convenient to devise a set of interfaces around any BTree
-        implementation so it can be swapped in and out.  The biggest concern with
-        such an approach are the differences between things like keys and the services
-        they offer like transaction support and replication.  Currently while
-        writing this, there are two know BTree implementations.  JDBM and JE from
-        Sleepy Cat which is still in Beta.  Later we may compare the two in depth however
-        the point remains that some abstraction will be required to be able to swap one
-        implementation in for the other.
-      </p>
-
-      <p>
-        For the first run we don't intend to worry about these concerns.  We will
-        incrementally refactor both implementations until commonalities can be
-        abstracted out of them.  Until then we focus our attention to just using each
-        BTree implemenation to the best of its ability.
-      </p>
-
-
-      <!--
-      <subsection name="Table Abstraction">
-          <p>
-            Rather than call it a BTree we're going to use a simple lookup table
-            abstraction.  You use a key to lookup a blob of something.  The underlying
-            search mechanism may change to include things like skiplists which are
-            probablistic BTrees.  Regardless we want to hide the underlying mechanism
-            and use a common denominator to access all implementations consistantly.
-          </p>
-
-          <p>
-            A table uses a key to access a value.  Two approaches have traditionally
-            been taken: use an Object as the key or use a simple primitive type as a
-            key.  Obviously there is a speed verses flexibility tradeoff.  Our take
-            here is to use the cheapest key we can find and a primitive type is best.
-            Some implementations may require the key to be wrapped and if so they pay
-            the price instead of all implementations paying the price.  Obviously the
-            implemenations using the primitive type will have much less overhead.
-          </p>
-
-          <p>
-            When primitive types are used associations require indices to correlate
-            values.
-          </p>
-      </subsection>
-
-      -->
-    </section>
-
-    <section name="Permission Map">
-        <p>
-          Applications manage a set of bit permissions within a bit vector.  Each
-          permission is associated with an application specific label and an index
-          within the bit vector.  Grants and denials are managed by setting the
-          appropriate bits in the index to 0 or 1.
-        </p>
-
-        <p>
-          An application defines the index at which a permission is located within
-          a permissions vector.  Permissions are looked up by application qualified
-          names and by their index value.  Point lookups for application permissions
-          will not occur: applications will have their entire permission map loaded
-          when they are loaded.  The permission set and size is often not restrictive
-          enough to warrent lazy loading on a per permission basis.  With these facts
-          in mind it makes sense to store an application's permissions in a raw binary
-          format using the application name as the lookup key.
-        </p>
-    </section>
-
-
-  </body>
-</document>
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>RMS JE Provider</title>
+  </properties>
+  <body>
+
+    <section name="Justification">
+      <p>
+        RMS requires a simple yet fast database where the relationships
+        between entities are known in advance.  The database may be large
+        in terms of the number entries per data type however the size of
+        the data in bytes will be small.
+      </p>
+
+      <p>
+        These requirements lead us to believe that the most optimal
+        configuration for an RMS implementation is a custom database
+        based on a btree implementation.  Such an implementation would
+        store data within B-Trees and associate keys programatically
+        to establish relationships between entities.
+      </p>
+
+      <p>
+        Searches would be extremely fast without the need for an interpreter
+        and access would be in constant time regardless of the size of the
+        database.  Access to a local database file is required for such an
+        implementation, hence some form of replication must exist to update
+        the contents of files when changes occur to the master RMS store.
+        The additional replication requirement occurs for all implementations
+        and is not a big concern since the data set is small and the frequency
+        of mutation is even smaller.
+      </p>
+      
+      <p>
+        JE is SleepCat's Java BTree implementation.  Building an RMS provider
+        based on JE is the target of this subproject.
+      </p>
+    </section>
+
+
+    <section name="Design">
+      <p>
+        It would be most convenient to devise a set of interfaces around any BTree
+        implementation so it can be swapped in and out.  The biggest concern with
+        such an approach are the differences between things like keys and the services
+        they offer like transaction support and replication.  Currently while
+        writing this, there are two know BTree implementations.  JDBM and JE from
+        Sleepy Cat which is still in Beta.  Later we may compare the two in depth however
+        the point remains that some abstraction will be required to be able to swap one
+        implementation in for the other.
+      </p>
+
+      <p>
+        For the first run we don't intend to worry about these concerns.  We will
+        incrementally refactor both implementations until commonalities can be
+        abstracted out of them.  Until then we focus our attention to just using each
+        BTree implemenation to the best of its ability.
+      </p>
+
+
+      <!--
+      <subsection name="Table Abstraction">
+          <p>
+            Rather than call it a BTree we're going to use a simple lookup table
+            abstraction.  You use a key to lookup a blob of something.  The underlying
+            search mechanism may change to include things like skiplists which are
+            probablistic BTrees.  Regardless we want to hide the underlying mechanism
+            and use a common denominator to access all implementations consistantly.
+          </p>
+
+          <p>
+            A table uses a key to access a value.  Two approaches have traditionally
+            been taken: use an Object as the key or use a simple primitive type as a
+            key.  Obviously there is a speed verses flexibility tradeoff.  Our take
+            here is to use the cheapest key we can find and a primitive type is best.
+            Some implementations may require the key to be wrapped and if so they pay
+            the price instead of all implementations paying the price.  Obviously the
+            implemenations using the primitive type will have much less overhead.
+          </p>
+
+          <p>
+            When primitive types are used associations require indices to correlate
+            values.
+          </p>
+      </subsection>
+
+      -->
+    </section>
+
+    <section name="Permission Map">
+        <p>
+          Applications manage a set of bit permissions within a bit vector.  Each
+          permission is associated with an application specific label and an index
+          within the bit vector.  Grants and denials are managed by setting the
+          appropriate bits in the index to 0 or 1.
+        </p>
+
+        <p>
+          An application defines the index at which a permission is located within
+          a permissions vector.  Permissions are looked up by application qualified
+          names and by their index value.  Point lookups for application permissions
+          will not occur: applications will have their entire permission map loaded
+          when they are loaded.  The permission set and size is often not restrictive
+          enough to warrent lazy loading on a per permission basis.  With these facts
+          in mind it makes sense to store an application's permissions in a raw binary
+          format using the application name as the lookup key.
+        </p>
+    </section>
+
+
+  </body>
+</document>

Modified: incubator/directory/rms/trunk/je/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/je/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/je/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
     <menu name="Resources">
       <item name="IRC" href="../../../irc.html"/>
-      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>
       <item name="Lists" href="../../../mailing-lists.html"/>
       <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/jndi/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/jndi/maven.xml	(original)
+++ incubator/directory/rms/trunk/jndi/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/jndi">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/jndi">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/jndi/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/jndi/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/jndi/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
     <menu name="Resources">
       <item name="IRC" href="../../../irc.html"/>
-      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>
       <item name="Lists" href="../../../mailing-lists.html"/>
       <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/project.xml
==============================================================================
--- incubator/directory/rms/trunk/project.xml	(original)
+++ incubator/directory/rms/trunk/project.xml	Mon Apr 12 09:39:28 2004
@@ -18,7 +18,7 @@
     <url>http://incubator.apache.org/directory</url>
 
     <issueTrackingUrl>
-      http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400
+      http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515
     </issueTrackingUrl>
     <siteAddress>incubator.apache.org</siteAddress>
     <siteDirectory>/home/akarasulu/public_html</siteDirectory>

Modified: incubator/directory/rms/trunk/spi/maven.xml
==============================================================================
--- incubator/directory/rms/trunk/spi/maven.xml	(original)
+++ incubator/directory/rms/trunk/spi/maven.xml	Mon Apr 12 09:39:28 2004
@@ -1,39 +1,39 @@
-<?xml version="1.0" encoding="ISO-8859-1"?> 
-  
-<project 
-  default="java:compile" 
-  xmlns:j="jelly:core" 
-  xmlns:u="jelly:util" 
-  xmlns:ant="jelly:ant" 
-  xmlns:maven="jelly:maven" 
-  xmlns:m="maven" 
-  xmlns:deploy="deploy"
-  >
-  
-  <preGoal name="site">
-    <attainGoal name="docbook:transform"/>
-  </preGoal>
-  
-  <postGoal name="site">
-    <attainGoal name="server:copy-images"/>
-    <attainGoal name="subproject:collectdocs"/>
-  </postGoal>
-
-  <goal name="subproject:collectdocs">
-    <ant:copy 
-      toDir="../target/docs/spi">
-      
-      <ant:fileSet dir="${basedir}/target/docs">
-        <ant:include name="**"/>
-      </ant:fileSet>
-    </ant:copy>
-  </goal>
-
-  <goal name="server:copy-images">
-    <copy toDir="target/docs/images">
-      <fileSet dir="${basedir}/src/images">
-        <include name="*.gif"/>
-      </fileSet>
-    </copy>
-  </goal>
-</project>
+<?xml version="1.0" encoding="ISO-8859-1"?> 
+  
+<project 
+  default="java:compile" 
+  xmlns:j="jelly:core" 
+  xmlns:u="jelly:util" 
+  xmlns:ant="jelly:ant" 
+  xmlns:maven="jelly:maven" 
+  xmlns:m="maven" 
+  xmlns:deploy="deploy"
+  >
+  
+  <preGoal name="site">
+    <attainGoal name="docbook:transform"/>
+  </preGoal>
+  
+  <postGoal name="site">
+    <attainGoal name="server:copy-images"/>
+    <attainGoal name="subproject:collectdocs"/>
+  </postGoal>
+
+  <goal name="subproject:collectdocs">
+    <ant:copy 
+      toDir="../target/docs/spi">
+      
+      <ant:fileSet dir="${basedir}/target/docs">
+        <ant:include name="**"/>
+      </ant:fileSet>
+    </ant:copy>
+  </goal>
+
+  <goal name="server:copy-images">
+    <copy toDir="target/docs/images">
+      <fileSet dir="${basedir}/src/images">
+        <include name="*.gif"/>
+      </fileSet>
+    </copy>
+  </goal>
+</project>

Modified: incubator/directory/rms/trunk/spi/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/spi/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/spi/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
      <menu name="Resources">
          <item name="IRC" href="../../../irc.html"/>
-         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+         <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
          <item name="Wiki" href="http://wiki.apache.org/directory"/>
          <item name="Lists" href="../../../mailing-lists.html"/>
          <item name="License" href="../../../license.html"/>

Modified: incubator/directory/rms/trunk/xdocs/navigation.xml
==============================================================================
--- incubator/directory/rms/trunk/xdocs/navigation.xml	(original)
+++ incubator/directory/rms/trunk/xdocs/navigation.xml	Mon Apr 12 09:39:28 2004
@@ -31,7 +31,7 @@
 
     <menu name="Resources">
       <item name="IRC" href="../../irc.html"/>
-      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
+      <item name="Jira" href="http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10515"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>
       <item name="Lists" href="../../mailing-lists.html"/>
       <item name="License" href="../../license.html"/>

Mime
View raw message