directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: rev 9514 - in incubator/directory/snickers/trunk: . xdocs xdocs/ber-codec xdocs/stub-compiler
Date Tue, 16 Mar 2004 03:50:05 GMT
Author: akarasulu
Date: Mon Mar 15 19:50:05 2004
New Revision: 9514

Added:
   incubator/directory/snickers/trunk/xdocs/stub-compiler/index.xml   (contents, props changed)
   incubator/directory/snickers/trunk/xdocs/stub-compiler/navigation.xml   (contents, props
changed)
Modified:
   incubator/directory/snickers/trunk/project.properties
   incubator/directory/snickers/trunk/project.xml
   incubator/directory/snickers/trunk/xdocs/ber-codec/design.xml
   incubator/directory/snickers/trunk/xdocs/ber-codec/index.xml
   incubator/directory/snickers/trunk/xdocs/ber-codec/navigation.xml
   incubator/directory/snickers/trunk/xdocs/index.xml
   incubator/directory/snickers/trunk/xdocs/navigation.xml
Log:
documentation updates

Modified: incubator/directory/snickers/trunk/project.properties
==============================================================================
--- incubator/directory/snickers/trunk/project.properties	(original)
+++ incubator/directory/snickers/trunk/project.properties	Mon Mar 15 19:50:05 2004
@@ -20,4 +20,4 @@
 maven.ui.banner.background=#FFFFFF
 maven.xdoc.includeProjectDocumentation=no
 maven.xdoc.poweredby.image=
-maven.xdoc.jsl = file:/${basedir}/../../../sitedocs/trunk/sitedocs/src/etc/site.jsl
+maven.xdoc.jsl = file:/${basedir}/../../sitedocs/trunk/sitedocs/src/etc/site.jsl

Modified: incubator/directory/snickers/trunk/project.xml
==============================================================================
--- incubator/directory/snickers/trunk/project.xml	(original)
+++ incubator/directory/snickers/trunk/project.xml	Mon Mar 15 19:50:05 2004
@@ -8,13 +8,13 @@
     <organization>
       <name>The Apache Incubator</name>
       <url>http://incubator.apache.org</url>
-      <logo>/images/apache-incubator-logo.png</logo>
+      <logo>http://incubator.apache.org/directory/images/apache-incubator-logo.png</logo>
     </organization>
 
     <inceptionYear>2003</inceptionYear>
     <package>org.apache.eve</package>
     
-    <logo>/images/apache-directory-logo.png</logo>
+    <logo>http://incubator.apache.org/directory/images/apache-directory-logo.png</logo>
     <url>http://incubator.apache.org/directory</url>
 
     <issueTrackingUrl>

Modified: incubator/directory/snickers/trunk/xdocs/ber-codec/design.xml
==============================================================================
--- incubator/directory/snickers/trunk/xdocs/ber-codec/design.xml	(original)
+++ incubator/directory/snickers/trunk/xdocs/ber-codec/design.xml	Mon Mar 15 19:50:05 2004
@@ -19,6 +19,25 @@
         general this decoder is viewed as a simple line parser for TLV tuples
         notifying of their arrival via callbacks.
       </p>
+      
+      <p>
+        The BER encoder and decoder (codec) will be designed to operate very
+        much like the Simple API for XML (SAX).  It will generate events which
+        are calls on a handler as it encounters low level encoded structures
+        called Tag Length Value (TLV) tuples.  
+      </p>
+      <p>
+        Rather than return values, which could be extremely large, in one peice
+        the decoder for example returns peices of a value until it completes 
+        processing the entire V of the TLV.  This makes the decoder highly 
+        attractive for servers using non-blocking IO and SocketChannels.  This
+        design gives it a small decoding footprint regardless of the size of 
+        the Protocol Data Unit (PDU) being processed.  It also makes it much
+        faster since the decoder deals with a small simple task without much
+        conditional logic for processing a PDU.  We hope the combined benefits
+        of non-blocking IO and this sleek codec, make any BER based protocol
+        server extremely responsive under heavy loads with massive concurrency.
+      </p>
     </section>
     
     <section name="Requirements">
@@ -33,7 +52,9 @@
         It should not try to interpret the content of the TLV tuples.  These 
         aspects are left to be handled by higher level content based facilities
         that build on top of the BERDecoder.  These higher facilities provide 
-        their own callbacks to build on TLV events.
+        their own callbacks to build on TLV events.  The SnickersDecoder which
+        transforms ASN.1 BER TLV Tuples into messages uses the BERDecoder in 
+        this way to give meaning to the arriving content.
       </p>
     </section>
     
@@ -54,46 +75,51 @@
         TLV members on the next event.  We leave the option to copy the TLV 
         upto the higher level facility that way only those TLV tuples of 
         interest, known only to the content specific handler, can be copied.
-        Why waste space and time within the decoder one those events that will
-        not be of interest?
+        <b>Why waste space and time on events that will are not of interest?</b>
       </p>
        
       <p>
         The most complex part of the decoder deals with maintaining state while
         decoding.  Data can arrive at any time to contain any part of a TLV or
-        multiple TLVs along with parts of others.  Often the fragmentation of
-        the data will not be known.  Furthermore the nesting of TLVs must be
-        tracked while maintaining state.  A stack is perhaps the best structure
-        to use to track the nesting of TLV tuples within a TLV tree.
+        multiple TLVs along with parts of others.  Often the fragmentation 
+        signature to the data along with its size will not be known.  
+        Furthermore the nesting of TLVs must be tracked while maintaining state.
+        A stack is used to track the nesting of TLV tuples within a TLV tree.
       </p>
       
       <p>
         We do not instantiate TLV tuple objects so pushing the one TLV instance 
         we reuse is pointless.  We could use two approaches here to handle this
-        nuisance.  First we could just create a new instance only for those TLV
+        issue.  First we could just create a new instance only for those TLV
         tuples that nest others and hence need to be pushed onto the stack.  Or
         we can use multiple primitive stacks based on an int to store the set
         of values contained in the tuple.  The second approach leads to greater
         complexity while the first leads to some overhead in extra instantiation
         time and memory which is negligable really.  Which approach is best 
         depends on the number of members in the tuple or in otherwords the 
-        number of primitive int stacks.
+        number of primitive int stacks used.
       </p>
       
       <p>
         We wrote a little test to figure out when one approach out performs the
-        other in the ObjectVersePrimitiveTest unit test case.  From tinkering
+        other in the ObjectVersePrimitiveTest stress test.  From tinkering
         with the parameters of the test case we found the use of primitives to
         out perform tuple object instantiation when the number of member stacks
         is less than or equal to 2.  If the number of stacks used is 3 or more
-        then instantiating an TLV object and pushing it onto one stack is best.
-        In our case we have 3 peices of information that need to be pushed and
-        poped together so from this data the choice is clear.  We clone the TLV
-        tuple or instantiate a new one for constructed TLVs that are pushed onto
-        a single stack.  This is faster and removes the need to manage multiple
-        stacks making the code less complex.
+        then instantiating a constructed TLV object and pushing it onto one 
+        stack is a better strategy.  In our case we have 3 peices of information
+        that need to be pushed and poped together so from this test data the 
+        choice is clear.  We clone the TLV tuple or instantiate a new one for 
+        constructed TLVs that are pushed onto a single stack.  This is faster 
+        and removes the need to manage multiple stacks making the code less 
+        complex.
       </p>
     </section>
     
+    <section name=" To be continued ... ">
+      <p>
+        More to come soon ...
+      </p>
+    </section>
   </body>
 </document>

Modified: incubator/directory/snickers/trunk/xdocs/ber-codec/index.xml
==============================================================================
--- incubator/directory/snickers/trunk/xdocs/ber-codec/index.xml	(original)
+++ incubator/directory/snickers/trunk/xdocs/ber-codec/index.xml	Mon Mar 15 19:50:05 2004
@@ -5,71 +5,94 @@
     <title>Snickers ASN.1 BER Library</title>
   </properties>
   <body>
-    <section name="News and Information">
-      <ul>
-        <li>
-	        26-JAN-2004: <a href="news.html">Created Snickers Sub-Project</a>
-        </li>
-      </ul>
-    </section>
-    <section name="What is it and why is it called Snickers?">
-      <p>
-        The Basic Encoding Rules (BER) Library is a simple encoding for Abstract
-        Syntax Notation One (ASN.1) defined data structures.  It replaces the
-        SNACC4J runtime libraries and adds some enhancements.  It's designed
-        for efficiency and speed specifically for use in SEDA based protocol 
-        servers using a BER codec for their Protocol Data Units (PDU).
-      </p>
-      <p>
-        Originally we used the SNACC4J compiler to generate stubs that knew how
-        to encode and decode themselves.  Due to licensing issues we had to 
-        abandon the use of SNACC4J.  Rather than reimplement it we decided to 
-        innovate on top of the algorithms used by Sample and Neufeld (the 
-        original creators of the first free SNAC compiler).  
-      </p>
-      <p>
-        A member of the directory team, Robb Penoyer, thought it was funny to
-        call whatever replaced the SNACC4J runtime, Snickers.  We think he was
-        hungry when he came up with this one.  Since then the name Snickers has 
-        stuck to the belly of the directory project and refers to everything 
-        dealing with ASN.1.
-      </p>
-    </section>
-    <section name="How will it work?">
+
+    <section name="Introduction">
       <p>
-        The BER encoder and decoder (codec) will be designed to operate very
-        much like the Simple API for XML (SAX).  It will generate events which
-        are calls on a handler as it encounters low level encoded structures
-        called Tag Length Value (TLV) triplets.  
-      </p>
-      <p>
-        Rather than return values, which could be extremely large, in one peice
-        the decoder for example returns peices of a value until it completes 
-        processing the entire V of the TLV.  This makes the decoder highly 
-        attractive for servers using non-blocking IO and SocketChannels.  This
-        design gives it a small decoding footprint regardless of the size of 
-        the Protocol Data Unit (PDU) being processed.  It also makes it much
-        faster since the decoder deals with a small simple task without much
-        conditional logic for processing a PDU.  We hope the combined benefits
-        of non-blocking IO and this sleek codec, make any BER based protocol
-        server extremely responsive under heavy loads with massive concurrency.
+        The Snickers BER codec runtime is based on the stateful codec interfaces
+        defined in the <a href="http://jakarta.apache.org/commons/codec">
+        commons-codec</a> API (hopefully these stateful codec interfaces make 
+        there way there).
+      </p>
+      
+      <p>
+        The stateful codec interfaces are designed for situations where data
+        is encoded or decoded in peices when those fragments of data are made
+        available.  Between actively encoding and decoding data the codec 
+        maintains the state of the operation which occurs in parts.  Such 
+        codecs are ideal for non-blocking stateful protocol servers that 
+        maintain a client socket connection for the life of a session.  The 
+        cost of establishing a client dedicated stateful encoder/decoder pair
+        is offset by the prolonged life of the connection.  Stateful codecs 
+        unlike their blocking stateless counterparts do not need to store the
+        entire encoded image of a request to decode since they do not have to
+        complete a [en]decode operation in one method call.
       </p>
     </section>
-    <section name="How to use the API">
+    
+    <section name="Usage">
       <p>
-        Fill this in once we have an API.
+        For more involved information concerning how the BER codec runtime is
+        designed and operates see the design documentation on the decoder 
+        <a href="./design.html">here</a>.
+      </p>
+      
+      <p>
+        The stateful codec interfaces standardize the use of the BER codec.
+        Below we show how a decoder can be established to be used within a 
+        standard selector based input detection loop.  This use case is by no
+        means specific to the SnickersDecoder, it is a characteristic of 
+        StatefulDecoders in general.  Below we show how the decoder is setup:
+      </p>
+      
+      <source>
+SnickersDecoder decoder = new SnickersDecoder( 512 ) ;
+DecoderCallback cb = new DecoderCallback() {
+  decodeOccurred( StatefulDecoder decoder, Object decoded ) {
+      MyClass.this.process( ( Message ) decoded ) ;
+  }
+};
+decoder.setCallback( cb ) ;
+      </source>
+      
+      <p>
+        The stateful decoder uses a callback to deliver completely decoded 
+        messages.  The <code>Message</code> interface which the <em>decoded</em>
+        object is cast to is the super interface used by the LDAP common message
+        API.  The objects returned are LDAP PDU message envelopes but they can 
+        be any Java stub generated for ASN.1 data types using the Snickers stub
+        compiler.
+      </p>
+      
+      <p>
+        Within a selector input detection loop which selects channels with
+        available input the decoder can be used to decode encoded BER messages.
+        The example below is a trivialized example of how the decoder can be 
+        used to decoded BER encoded data in parts as a message arrives 
+        fragmented by the tcp/ip stack:
+      </p>
+      
+      <source>
+while ( true ) {
+  ...
+  SelectionKey key = ( SelectionKey ) list.next() ;
+  if ( key.isReadable() ) {
+    SocketChannel channel = ( SocketChannel ) l_key.channel() ;
+    channel.read( buf ) ;
+    buf.flip() ;
+    decoder.decode( buf ) ;
+  }
+  ...
+}
+      </source>
+      
+      <p>
+        As you can see from the code fragment and the API for the decode 
+        operation the decode does not return anything.  In fact the return
+        is void.  Because the callback is used to deliver the finished product
+        when it is ready the decode operation can occur asynchronously in 
+        another thread or stage of a server.  This is what makes 
+        StatefulDecoders and the SnickersDecoder in particular so exciting.
       </p>
-      <subsection name="Some Sub-Topic">
-        <p>
-          Fill this in.
-        </p>
-      </subsection>
-      <subsection name="General Resources">
-        <ul>
-          <li><a href="rt.html">Random Thoughts</a></li>
-          <li><a href="eureka.html">Eureka!</a></li>
-        </ul>
-      </subsection>
     </section>
   </body>
 </document>

Modified: incubator/directory/snickers/trunk/xdocs/ber-codec/navigation.xml
==============================================================================
--- incubator/directory/snickers/trunk/xdocs/ber-codec/navigation.xml	(original)
+++ incubator/directory/snickers/trunk/xdocs/ber-codec/navigation.xml	Mon Mar 15 19:50:05
2004
@@ -1,29 +1,52 @@
 <?xml version="1.0" encoding="UTF-8"?>
 
-<project>
-  <title>Apache Directory</title>
-  <body>
-    <links>
-      <item name="Apache" href="http://apache.org/"/>
-      <item name="Snickers" 
-        href="http://incubator.apache.org/directory/snickers"/>
-      <item name="Directory" href="http://incubator.apache.org/directory"/>
-    </links>
-    <menu name="About Snickers">
-      <item name="top item0" href="/empty/index.html"/>
-      <item name="top item1" href="/empty/index.html"/>
-      <item name="top item2" href="/empty/index.html"/>
-      <item name="BER Library" href="/index.html">
-        <item name="Overview" href="/index.html"/>
-        <item name="Design" href="/design.html"/>
-        <item name="Latest News" href="/news.html"/>
-        <item name="Random Thoughts" href="/rt.html"/>
-        <item name="Eureka" href="/eureka.html"/>
-        <item name="Sample's Original SNACC" 
-          href="http://www.apache.org/~akarasulu/resources/ASN.1/snacc.pdf"/>
-      </item>
-      <item name="top item3" href="/empty/index.html"/>
-      <item name="top item4" href="/empty/index.html"/>
-    </menu>
-  </body>
+<project>
+
+ <title>Apache Directory Project</title>
+
+ <body>
+
+    <links>
+      <item name="Apache" href="http://apache.org/"/>
+      <item name="Directory" href="../../index.html"/>
+      <item name="Eve" href="../eve/index.html"/>
+      <item name="LDAP" href="../ldap/index.html"/>
+      <item name="Naming" href="../naming/index.html"/>
+      <item name="Janus" href="../janus/index.html"/>
+      <item name="Snickers" href="/index.html"/>
+      <item name="Sitedocs" href="../sitedocs/index.html"/>
+    </links>
+
+    <menu name="About Directory">
+      <item name="Overview" href="../../index.html"/>
+      <item name="Community" href="../../community/index.html"/>
+      <item name="Latest News" href="../../news.html"/>
+      <item name="Subprojects" href="../../index.html">
+        <item name="Eve" href="../eve/index.html"/>
+        <item name="LDAP" href="../ldap/index.html"/>
+        <item name="Janus" href="../janus/index.html"/>
+        <item name="Naming" href="../naming/index.html"/>
+        <item name="Snickers" href="/index.html">
+          <item name="BER Codec" href="/ber-codec/index.html"/>
+          <item name="Stub Compiler" href="/stub-compiler/index.html"/>
+        </item>
+        <item name="Sitedocs" href="../sitedocs/index.html"/>
+      </item>
+      <item name="Documentation" href="../../doc/index.html"/>
+    </menu>
+
+    <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="Wiki" href="http://wiki.apache.org/directory"/>
+      <item name="Lists" href="../../mailing-lists.html"/>
+      <item name="License" href="../../license.html"/>
+      <item name="Sandbox" href="../../sandbox/index.html"/>
+      <item name="Downloads" href="../../download.cgi"/>
+      <item name="Subversion" href="../../svn.html"/>
+      <item name="Related Projects" href="../../related/index.html"/>
+    </menu>
+ </body>
+
 </project>

Modified: incubator/directory/snickers/trunk/xdocs/index.xml
==============================================================================
--- incubator/directory/snickers/trunk/xdocs/index.xml	(original)
+++ incubator/directory/snickers/trunk/xdocs/index.xml	Mon Mar 15 19:50:05 2004
@@ -6,44 +6,15 @@
   </properties> 
 
   <body>
-    <section name="Introduction">
-      <p>
-        While writing a SEDA based LDAP server in Java using NIO selectable 
-        channels it occurred to us that blocking until a full message is 
-        decoded was a big waste.  It undermines the benefits of using selectors,
-        uses extra threads and requires much more memory.  Actually if we have
-        to collect all of a message before we can decode it with a blocking 
-        decoder then we're in trouble.  A little over twice the memory footprint
-        of each message must be used to decode BER encoded PDUs.  Similar yet 
-        different inefficiencies exist with the other direction as well.
-      </p>
-      
-      <p>
-        Looking at the ASN.1 landscape there really aren't that many free open
-        source ASN.1 BER codecs out there written for Java.  Actually there are
-        none with our performance requirements.  So we started to build one 
-        while weaning ourselves off of Snacc4J which was mysteriously removed 
-        from the Open Source world by IBM.
-      </p>
-      
-      <p>
-        Snickers hence is a high performance replacement optimized for use with
-        selectable channels and non blocking IO.  It is composed of several 
-        runtime APIs and will eventually provide tools to generate Java stubs
-        for various ASN.1 type definitions.  In a sense Snickers is a Snacc4J
-        replacement with a lot more to keep ASN.1 based server implementors 
-        satisfied.
-      </p>
-    </section>
-    
     <section name="Overview">
       <p>
-        There are a few sub subprojects associated with snickers.  Some have 
-        yet to begin and others may exist in a form that satisfies up until now
-        the needs of the Eve directory server.  As time passes these holes will
-        be filled in.
+        Snickers is a high performance non-blocking replacement for the Snacc4J
+        runtime and its Java stub compiler for ASN.1.  It is designed from the
+        ground up to work with NIO constructs like Channels and Buffers.  There 
+        are currently two sub subprojects associated with snickers which are 
+        described below:
       </p>
-      
+
       <table>
         <tr><th>Subproject</th><th>Description</th></tr>
         
@@ -51,29 +22,70 @@
           <td><a href="ber-codec/index.html">BER Codec</a></td>
           <td>
             ASN.1 data structures are encoded onto and decoded off of the wire
-            using these codecs.  They deal with simple Tag Value Length or TLV 
-            tuples which is the lowest means to interpret BER encoded data.  
-            Other more complex codec implementations are also present within 
-            this project.  They build on top of the simple BER/TLV codecs to
-            decode and populate Java ASN.1 stubs or encode and serialize them 
-            onto BER streams.
+            using the Basic Encoding Rules (BER) codec.
           </td>
         </tr>
         
         <tr>
           <td><a href="stub-compiler/index.html">Java Stub Compiler</a></td>
           <td>
-            Java interfaces and implementations are generated to represent 
-            complex ASN.1 data types according to an ASN.1 specification for 
-            the datatype.  Factory classes for each data type are also generated
-            as peer classes to encode and decode entire interfaces.  The 
-            Snickers BER Codec runtime uses these factories, and interfaces to 
-            encode and decode protocol data types on the wire.  As a matter of 
-            fact these factories really are designed as higher level Stateful 
-            decoder's and encoders.
+            The Snickers ASN.1 Java Stub Compiler generates interfaces and 
+            classes for complex ASN.1 data types.  These classes are used with
+            the BER codec runtime API to marshal and demarshal protocol data
+            units (PDU).
           </td>
         </tr>
       </table>
+    </section>
+
+    <section name="Motivation">
+      <p>
+        Non-blocking IO in stateful protocol servers imposes higher performance
+        requirements on codecs.  In the Eve Directory Server, the BER codec 
+        must be fast, efficient, and take a very small relatively fixed 
+        size memory footprint while actively encoding or decoding messages.
+      </p>
+
+      <p>
+        To begin with ASN.1 BER codecs for Java are few and far between.  More
+        importantly no BSD license compatible open source API is available.  
+        Snacc4J from IBM was used initially but it has mysteriously disappeared
+        and is no longer supported.  Furthermore it is completely incompatible
+        with any licence we know of: it's practically not even Open Source.  
+        Even with license issues Snacc4J is terribly inefficient and imposes 
+        security threats especially where decodes are concerned.  Snacc4J 
+        decoders block until an entire message is read and decoded.  They hence 
+        require approximately twice the transfer footprint of a message to 
+        decode it and there is no limit to the accepted transfer footprint size.
+        DoS attacks could easily be mounted using a single large request to bog
+        down the server making it unresponsive.
+      </p>
+
+      <p>
+        Snickers is a high performance runtime codec optimized for use with
+        selectable channels and non blocking IO.  Snickers is destined to 
+        replace stateless BER codecs, and keep ASN.1 based protocol server
+        implementors satisfied.  A user definable parameter is used to set the 
+        fixed in memory footprint of the decoder while actively decoding ASN.1 
+        data structures encoded using Basic Encoding Rules.  Furthermore, when 
+        large indivisible parts of messages like byte[] fields are encountered,
+        they are streamed to disk and referred to using a URL rather than 
+        allocating the memory to store such an object.  Note: this experimental
+        feature is being added as we speak.  Access to the object is granted to 
+        the application via the URL.  The handling of the large streamable data 
+        is left to the discretion of the application.
+      </p>
+    </section>
+    
+    <section name="Why is it called Snickers?">
+      <p>
+        A member of the directory team, Robb Penoyer, thought it was funny to
+        call whatever replaced the SNACC4J runtime, Snickers.  We think he was
+        hungry when he came up with this one.  Since then the name Snickers has 
+        stuck however we use it to refer to anything we build dealing with 
+        ASN.1.  So look out for other Snickers codecs in the future using PER,
+        DER, or XER.  I'm sure the need will arise at some point.
+      </p>
     </section>
   </body>
 </document>

Modified: incubator/directory/snickers/trunk/xdocs/navigation.xml
==============================================================================
--- incubator/directory/snickers/trunk/xdocs/navigation.xml	(original)
+++ incubator/directory/snickers/trunk/xdocs/navigation.xml	Mon Mar 15 19:50:05 2004
@@ -8,41 +8,44 @@
 
     <links>
       <item name="Apache" href="http://apache.org/"/>
-      <item name="Directory" href="/index.html"/>
-      <item name="Eve" href="/subprojects/eve/index.html"/>
-      <item name="LDAP" href="/subprojects/ldap/index.html"/>
-      <item name="Naming" href="/subprojects/naming/index.html"/>
-      <item name="Janus" href="/subprojects/janus/index.html"/>
-      <item name="Snickers" href="/subprojects/snickers/index.html"/>
-      <item name="Sitedocs" href="/subprojects/sitedocs/index.html"/>
+      <item name="Directory" href="../../index.html"/>
+      <item name="Eve" href="../eve/index.html"/>
+      <item name="LDAP" href="../ldap/index.html"/>
+      <item name="Naming" href="../naming/index.html"/>
+      <item name="Janus" href="../janus/index.html"/>
+      <item name="Snickers" href="/index.html"/>
+      <item name="Sitedocs" href="../sitedocs/index.html"/>
     </links>
 
     <menu name="About Directory">
-      <item name="Overview" href="/index.html"/>
-      <item name="Community" href="/community/index.html"/>
-      <item name="Latest News" href="/news.html"/>
-      <item name="Subprojects" href="/subprojects/index.html">
-        <item name="Eve" href="/subprojects/eve/index.html"/>
-        <item name="LDAP" href="/subprojects/ldap/index.html"/>
-        <item name="Janus" href="/subprojects/janus/index.html"/>
-        <item name="Naming" href="/subprojects/naming/index.html"/>
-        <item name="Snickers" href="/subprojects/snickers/index.html"/>
-        <item name="Sitedocs" href="/subprojects/sitedocs/index.html"/>
+      <item name="Overview" href="../../index.html"/>
+      <item name="Community" href="../../community/index.html"/>
+      <item name="Latest News" href="../../news.html"/>
+      <item name="Subprojects" href="../../index.html">
+        <item name="Eve" href="../eve/index.html"/>
+        <item name="LDAP" href="../ldap/index.html"/>
+        <item name="Janus" href="../janus/index.html"/>
+        <item name="Naming" href="../naming/index.html"/>
+        <item name="Snickers" href="/index.html">
+          <item name="BER Codec" href="/ber-codec/index.html"/>
+          <item name="Stub Compiler" href="/stub-compiler/index.html"/>
+        </item>
+        <item name="Sitedocs" href="../sitedocs/index.html"/>
       </item>
-      <item name="Documentation" href="/doc/index.html"/>
+      <item name="Documentation" href="../../doc/index.html"/>
     </menu>
 
     <menu name="Resources">
-      <item name="IRC" href="/irc.html"/>
+      <item name="IRC" href="../../irc.html"/>
       <item name="Jira" href=
         "http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>
-      <item name="Lists" href="/mailing-lists.html"/>
-      <item name="License" href="/license.html"/>
-      <item name="Sandbox" href="/sandbox/index.html"/>
-      <item name="Downloads" href="/download.cgi"/>
-      <item name="Subversion" href="/svn.html"/>
-      <item name="Related Projects" href="/related/index.html"/>
+      <item name="Lists" href="../../mailing-lists.html"/>
+      <item name="License" href="../../license.html"/>
+      <item name="Sandbox" href="../../sandbox/index.html"/>
+      <item name="Downloads" href="../../download.cgi"/>
+      <item name="Subversion" href="../../svn.html"/>
+      <item name="Related Projects" href="../../related/index.html"/>
     </menu>
  </body>
 

Added: incubator/directory/snickers/trunk/xdocs/stub-compiler/index.xml
==============================================================================
--- (empty file)
+++ incubator/directory/snickers/trunk/xdocs/stub-compiler/index.xml	Mon Mar 15 19:50:05 2004
@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>Snickers ASN.1 Java Stub Compiler</title>
+  </properties>
+  <body>
+    <section name="Coming soon ...">
+      <p>
+        Coming soon ...
+      </p>
+    </section>
+  </body>
+</document>

Added: incubator/directory/snickers/trunk/xdocs/stub-compiler/navigation.xml
==============================================================================
--- (empty file)
+++ incubator/directory/snickers/trunk/xdocs/stub-compiler/navigation.xml	Mon Mar 15 19:50:05
2004
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<project>
+
+ <title>Apache Directory Project</title>
+
+ <body>
+
+    <links>
+      <item name="Apache" href="http://apache.org/"/>
+      <item name="Directory" href="../../index.html"/>
+      <item name="Eve" href="../eve/index.html"/>
+      <item name="LDAP" href="../ldap/index.html"/>
+      <item name="Naming" href="../naming/index.html"/>
+      <item name="Janus" href="../janus/index.html"/>
+      <item name="Snickers" href="/index.html"/>
+      <item name="Sitedocs" href="../sitedocs/index.html"/>
+    </links>
+
+    <menu name="About Directory">
+      <item name="Overview" href="../../index.html"/>
+      <item name="Community" href="../../community/index.html"/>
+      <item name="Latest News" href="../../news.html"/>
+      <item name="Subprojects" href="../../index.html">
+        <item name="Eve" href="../eve/index.html"/>
+        <item name="LDAP" href="../ldap/index.html"/>
+        <item name="Janus" href="../janus/index.html"/>
+        <item name="Naming" href="../naming/index.html"/>
+        <item name="Snickers" href="/index.html">
+          <item name="BER Codec" href="/ber-codec/index.html"/>
+          <item name="Stub Compiler" href="/stub-compiler/index.html"/>
+        </item>
+        <item name="Sitedocs" href="../sitedocs/index.html"/>
+      </item>
+      <item name="Documentation" href="../../doc/index.html"/>
+    </menu>
+
+    <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="Wiki" href="http://wiki.apache.org/directory"/>
+      <item name="Lists" href="../../mailing-lists.html"/>
+      <item name="License" href="../../license.html"/>
+      <item name="Sandbox" href="../../sandbox/index.html"/>
+      <item name="Downloads" href="../../download.cgi"/>
+      <item name="Subversion" href="../../svn.html"/>
+      <item name="Related Projects" href="../../related/index.html"/>
+    </menu>
+ </body>
+
+</project>

Mime
View raw message