directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: rev 6408 - in incubator/directory/sitedocs/trunk/sitedocs/xdocs: . images
Date Sun, 01 Feb 2004 18:15:23 GMT
Author: akarasulu
Date: Sun Feb  1 10:15:23 2004
New Revision: 6408

   incubator/directory/sitedocs/trunk/sitedocs/xdocs/images/asf_logo_wide.gif   (contents,
props changed)
Added project proposal from wiki that will go away after a while as static 

Added: incubator/directory/sitedocs/trunk/sitedocs/xdocs/images/asf_logo_wide.gif
Binary file. No diff available.

Modified: incubator/directory/sitedocs/trunk/sitedocs/xdocs/news.xml
--- incubator/directory/sitedocs/trunk/sitedocs/xdocs/news.xml	(original)
+++ incubator/directory/sitedocs/trunk/sitedocs/xdocs/news.xml	Sun Feb  1 10:15:23 2004
@@ -18,8 +18,7 @@
           Apache Directory TLP upon matriculation from the incubator. 
-          The original proposal can be found <a href=
-          "">
+          The original proposal can be found <a href="./project-proposal.html">
           here</a>.  Thanks to all those that made it happen! 

Added: incubator/directory/sitedocs/trunk/sitedocs/xdocs/project-proposal.html
--- (empty file)
+++ incubator/directory/sitedocs/trunk/sitedocs/xdocs/project-proposal.html	Sun Feb  1 10:15:23
@@ -0,0 +1,360 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<!-- saved from url=(0067)
+<HTML><HEAD><TITLE>Apache Wiki: ApacheDirectoryProject</TITLE>
+<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
+<BODY text=black vLink=purple link=blue bgColor=white>
+<H1><A href=""><IMG 
+alt=[Home] src="./images/asf_logo_wide.gif" border=0></A><A 

+href="">HomePage</A> | <A


+| <A 
+<H1>Proposal for an Apache Directory Project</H1><EM>10 Sept 2003, Alex
+( LDAPd Group Founder</EM> 
+<P><STRONG>Section 0 : Rationale</STRONG> 
+<P>The geometric growth of networks, services, distributed systems, and their 
+components has brought about a revival of interest in directories. Directories 
+are no longer considered commodity products used to store a phone book or list 
+of users. Directories and LDAP have grown into a critical technology that will 
+inevitably become a cornerstone of distributed systems. Several software giants 
+like BEA, SUN, and Microsoft have already demonstrated their belief in this 
+outcome by heavily integrating their products with directories. Directory and 
+naming systems are being used in everything from a simplified form for J2EE 
+configuration to full-blown enterprise directories, within identity management 
+systems and distributed computing platforms like JINI. 
+<P>The overhead of managing several copies of relatively static information 
+across systems and enterprises is daunting and introduces the potential for data 
+inconsistency. The frequently replicated user and group tables in almost every 
+database driven application alone is a testament to this fact. When multiple 
+systems have to inter operate, they must share access to common information, and 
+directories are the best storage paradigm for rapidly accessing this type of 
+data. Whether the information to be stored, is a component's configuration, a 
+user's security profile, a business rule or a business process, directories are 
+the place to store it for centralized management, and distribution across 
+<P>To date, a fully compliant pure Java open source LDAPv3 server has not yet 
+been written. This is partially due to the fact that a practical stateful 
+protocol server in Java was virtually impossible until the introduction of the 
+NIO packages in the 1.4 SDK. LDAP, as a stateful protocol, manages client state 
+through a TCP socket connection. The socket connection persists through several 
+client requests and server responses tying them together under a logical session 
+or conversation. Before the introduction of non-blocking IO in the NIO packages 
+of the 1.4 SDK, a thread had to be dedicated to each socket to detect IO. A 
+stateful protocol server written completely in Java, would have needed as many 
+active threads as the number of concurrent clients. Theoretically, scalability 
+would have been very poor; the performance curve would be asymptotic, degrading 
+rapidly with an increase in the number of concurrent connections. To scale pure 
+Java statefull protocol server implementations had to wait until the Merlin 
+release of the JDK. 
+<P>Furthermore, no embeddable pure Java LDAPv3 server has yet been written and 
+made freely available. We believe the embedding of LDAP servers into existing 
+mail, application and web servers to be the next logical steps in the 
+progression and integration of LDAP. Several commercial examples can already be 
+sited: Microsoft Exchange and BEA Weblogic Server. The management benefits of 
+coupling these servers with an LDAP server are beyond the scope of this proposal 
+and left to the imagination of the reader. However, the synergy between embedded 
+LDAP servers and other flagship Apache servers would lead to greater economies 
+of scale for the Apache server suite and reduce the overhead of management for 
+the Apache software user community. 
+<P>LDAP directories are specialized databases, however unlike their RDBMS 
+counterparts, LDAP directories are fairly new and for this reason lack rich 
+integration features. High on the list of features lacking in LDAP servers are 
+stored procedures and triggers. Triggers and Java stored procedures would expand 
+the horizon of LDAP in itself even without the benefits of Java. Triggers and 
+stored procedures would alleviate ugly workarounds which currently using polling 
+and meta directories. These features alone would attract groups within the LDAP 
+and Java communities to band together and support the Apache LDAP Project. 
+<P>LDAP is both a network line protocol and a hierarchical relational database. 
+Some might even argue that LDAP is object oriented. Regardless, the 
+implementation of an LDAP server is not a trivial matter. LDAP code bases 
+written in native languages have to be ported to run on different platforms. 
+Conditional complies in C based implementations were shown to considerably 
+reduce the maintainability of code bases. The complexity of a database, a 
+network line protocol and conditional compilation together have resulted in 
+reduced maintainability for C based LDAP servers. Also the learning curve and 
+hence barrier to entry for developers is greater. These complications would not 
+exist for a Java based LDAP server that is written once and can run anywhere. 
+<P>The Apache Foundation supports several component container projects which 
+provide the proper foundation for a Java LDAP directory server. Apache also 
+supports several server side application containers which can realize 
+significant functional enhancements by employing an LDAP directory server. Also 
+LDAP requiring organizations today must settle for less than optimal 
+implementations and often have to pay as high as a dollar per entry to directory 
+enable their applications. The Apache LDAP Project would solve these problems by 
+providing a free robust LDAPv3 implementation in a standalone configuration or 
+an embeddable configuration for use in all Apache servers and other third party 
+<P>Our goal is to produce a community of developers with backgrounds in LDAP, 
+X.500, Database Engineering and JNDI tasked with the development of pure Java 
+LDAPv3 Clients, APIs, JNDI providers and LDAPv3 compliant servers with the 
+aforementioned features. The produced software will be ASF licensed. Where 
+applicable the best available ASF/BSD licensed code will be reused and new code 
+will be added to complete the LDAPv3 protocol as defined in <A 
+href="">[RFC 3377]</A> and its associated 8 
+RFCs listed below: 
+  <LI><A href="">[RFC2251]</A> Lightweight

+  Directory Access Protocol (v3): LDAP on-the-wire protocol 
+  <LI><A href="">[RFC2252]</A> Lightweight

+  Directory Access Protocol (v3): Attribute Syntax Definitions 
+  <LI><A href="">[RFC2253]</A> Lightweight

+  Directory Access Protocol (v3): UTF-8 String Representation of DNs 
+  <LI><A href="">[RFC2254]</A> The String

+  Representation of LDAP Search Filters 
+  <LI><A href="">[RFC2255]</A> The LDAP
+  Format 
+  <LI><A href="">[RFC2256]</A> A Summary
+  the X.500(96) User Schema for use with LDAPv3 
+  <LI><A href="">[RFC2829]</A> Authentication

+  Methods for LDAP 
+  <LI><A href="">[RFC2830]</A> Lightweight

+  Directory Access Protocol (v3): Extension for Transport Layer Security 
+<P>Additionally, the schema objects specified within the following RFCs will be 
+defined for use and partial or full complaince will be met where relavent to the 
+  <LI><A href="">[RFC1274]</A> The COSINE
+  Internet X.500 Schema 
+  <LI><A href="">[RFC1804]</A> Schema

+  Publishing in X.500 Directory 
+  <LI><A href="">[RFC2079]</A> Definition
+  an X.500 Attribute Type and an Object Class to Hold Uniform Resource 
+  Identifiers (URIs) 
+  <LI><A href="">[RFC2247]</A> Using
+  in LDAP/X.500 Distinguished Names 
+  <LI><A href="">[RFC2293]</A> Representing

+  Tables and Subtrees in the X.500 Directory 
+  <LI><A href="">[RFC2294]</A> Representing

+  the O/R Address hierarchy in the X.500 Directory Information Tree 
+  <LI><A href="">[RFC2307]</A> An Approach

+  for Using LDAP as a Network Information Service 
+  <LI><A href="">[RFC2377]</A> Naming
+  for Internet Directory-Enabled Applications 
+  <LI><A href="">[RFC2587]</A> Internet
+  Public Key Infrastructure LDAPv2 Schema 
+  <LI><A href="">[RFC2589]</A> Lightweight

+  Directory Access Protocol (v3): Extensions for Dynamic Directory Services 
+  <LI><A href="">[RFC2596]</A> Use of

+  Language Codes in LDAP 
+  <LI><A href="">[RFC2649]</A> An LDAP

+  Control and Schema for Holding Operation Signatures 
+  <LI><A href="">[RFC2696]</A> LDAP
+  Extension for Simple Paged Results Manipulation 
+  <LI><A href="">[RFC2713]</A> Schema
+  Representing Java(tm) Objects in an LDAP Directory 
+  <LI><A href="">[RFC2714]</A> Schema
+  Representing CORBA Object References in an LDAP Directory 
+  <LI><A href="">[RFC2798]</A> Definition
+  the inetOrgPerson<A 
+  href=";id=OrgPerson">?</A>

+  LDAP Object Class 
+  <LI><A href="">[RFC2829]</A> Authentication

+  Methods for LDAP 
+  <LI><A href="">[RFC2830]</A> Lightweight

+  Directory Access Protocol (v3): Extension for Transport Layer Security 
+  <LI><A href="">[RFC2849]</A> The LDAP
+  Interchange Format (LDIF) - Technical Specification 
+  <LI><A href="">[RFC2891]</A> LDAP
+  Extension for Server Side Sorting of Search Results 
+  <LI><A href="">[RFC3045]</A> Storing
+  Information in the LDAP root DSE 
+  <LI><A href="">[RFC3062]</A> LDAP
+  Modify Extended Operation 
+  <LI><A href="">[RFC3088]</A> OpenLDAP<A

+  href=";id=OpenLDAP">?</A>

+  Root Service An experimental LDAP referral service 
+  <LI><A href="">[RFC3112]</A> LDAP

+  Authentication Password Schema 
+  <LI><A href="">[RFC3296]</A> Named

+  Subordinate References in Lightweight Directory Access Protocol (LDAP) 
+  Directories 
+  <LI><A href="">[RFC3383]</A> Internet

+  Assigned Numbers Authority (IANA) considerations for the Lightweight Directory 
+  Access Protocol (LDAP) </LI></UL>
+<P><STRONG>Section 0.1 : Criteria</STRONG> 
+<P>We feel that this project has a good chance for success as the following 
+project aspects are carefully considered : 
+<P><EM>Meritocracy:</EM> The project will be meritocratic - the usual Apache

+meritocracy rules would apply. 
+<P><EM>Community:</EM> The user community for this project is potentially

+massive. The initial developer community for this project consists of developers 
+from Apache and LDAPd projects. The aim is for this community to grow 
+considerably once this project enters the incubator. 
+<P><EM>Core Developers:</EM> The initial developers are listed further
+within this document and consist of some existing Apache committers together 
+with committers from the LDAPd Group. 
+<P><EM>Alignment:</EM> There is clear alignment with many existing Apache

+projects. From Jakarta projects such as Tomcat, James and Slide for embedding 
+LDAP. The LDAP DSML standards will eventually require the use of several XML 
+projects. Other projects like OpenJms<A 

+which currently are not Apache projects but very well may be in the future will 
+be used for things like replication. Jdbm likewise is used for building Btree 
+based indices for custom databases. Also projects like Apache Xindice may be 
+leveraged for an XML based backend or for DSML enabling subsystems of an LDAP 
+<P>We see the Apache Directory Project as a separate project to existing Apache 
+projects, serving several roles 
+  <LI>Home for Apache Directory Client APIs and Client Scripts 
+  <LI>Home for Apache JNDI Providers for Various Directory Namespaces 
+  <LI>Home for Apache Directory Servers 
+  <LI>May also become home to an ASN.1 Encoding/Decoding<A 
+  href=";id=ApacheDirectoryProject/Decoding">?</A>

+  Library </LI></UL>
+<P><STRONG>Section 0.2 : Warning Signs</STRONG> 
+<P>We feel this project has a good chance for success as the following warning 
+signs do not apply to the project we are proposing: 
+<P><EM>Orphaned products:</EM> This project is starting with an existing
+base which using lots of the high quality open source code out there which is 
+ASF/BSD licensed. 
+<P><EM>Inexperience with open source:</EM> The initial community is made
up of 
+existing Apache and LDAPd Group committers exclusively so the open source 
+experience is there to varying degrees. 
+<P><EM>Reliance on salaried developers:</EM> None of the initial developers
+currently paid to work on the Directory Project. 
+<P><EM>No ties to other Apache products:</EM> The Apache Directory Project
+complementary to existing technologies at Apache. LDAPd currently uses Avalon 
+and will eventually be used by james. LDAPd will eventually integrate into 
+Geronimo. The Apache Directory Project will integrate with, and possibly 
+subsume, Jakarta Commons Naming. 
+<P><EM>A fascination with the Apache brand:</EM> The committers are interested

+in developing a healthy open source community around ASF/BSD licensed directory 
+servers and their clients along with other JNDI accessible name spaces. Is 
+Apache the right place? We think it is. Several Apache folks have already shown 
+interest in LDAPd, the seed code base to be used for this project. In fact the 
+LDAPd Group was initially approached by Apache to submit an Incubator proposal. 
+LDAPd Group members voted unanimously to donate the code to Apache in an effort 
+to build the next flagship server at Apache and much more. 
+<P><STRONG>Section 1 : Scope of the Project</STRONG> 
+<P>There are multiple goals for this Apache project: 
+  <LI>Promote a healthy open source community! 
+  <LI>Promote a language agnostic environment for both client side and server 
+  side endeavors. 
+  <LI>A one stop location for all directory and naming needs on any platform or 
+  any language. 
+  <UL>
+    <LI>client APIs 
+    <LI>clients 
+    <LI>JNDI providers for Java and other namespaces. 
+    <LI>May also include an LDAP protocol correctness and stress testing suite 
+    in the future. </LI></UL>
+  <LI>Provide servers in embeddable configurations. 
+  <LI>Provide servers in standalone configurations as UNIX daemons or NT 
+  Services. 
+  <LI>Provide support for Directory Server embedding or integration with 
+  existing Apache servers like httpd, Slide, Tomcat, James and Geronimo. 
+<P><STRONG>Section 2 : Initial Source</STRONG> 
+<P>The initial code base from which to create the Apache Directory repository is 
+contained mostly at Sourceforge under the LDAPd project accessible <A 
+href="">[here]</A>. This code base must 
+assign copyright to the Apache Software Foundation. The code base will need to 
+be licensed under The Apache Software Foundation license. The license file in 
+every subproject will be changed to the Apache license. The current license is 
+already an Apache "style" license, so this change is basically a change to name 
+The ASF as the owner. 
+<P>The proposed TLP (after incubation) would have an one or more directory 
+servers with multiple datastore backends, a JNDI context for J2EE configuration, 
+JNDI service provider(s) for LDAP and other transports, State and Object 
+Factories suitable for use in the various Context/DirContext<A 

+implementations, etc. 
+<P>Beside source code the LDAPd Group must transfer its IANA assigned ASN.1 
+Object Identifier to Apache Software Foundation. 
+<P><STRONG>Section 3 : ASF Resources to be Created</STRONG> 
+<P><EM>Section 3.1 : Mailing Lists</EM> 
+  <LI> </LI></UL>
+<P><EM>Section 3.2 : CVS Repositories</EM> 
+  <LI>incubator-directory </LI></UL>
+<P><EM>Section 3.3 : Bugzilla or (preferably) Jira</EM> 
+  <LI>directory </LI></UL>
+<P><STRONG>Section 4 : Initial Set of Committers</STRONG> 
+<P>All contributors must sign and submit a Contributors License Agreement. The 
+following individuals are the contributors, and have signed and sent the 
+agreement at one time or another: 
+  <LI>Alex Karasulu 
+  <LI>Phil Steitz 
+  <LI>Robb Penoyer 
+  <LI>Noel Bergman 
+  <LI>Jeff Machols 
+  <LI>Henri Yandell 
+  <LI>Wes McKean<A 
+  href=";id=McKean">?</A>

+  </LI></UL>
+<P><STRONG>Section 5 : Apache Sponsoring Individuals</STRONG> 
+  <LI>Nicola Ken Barozzi (Apache Incubator) 
+  <LI>Noel J. Bergman (Apache James) 
+  <LI>Henri Yandell (Jakarta Commons Naming) 
+  <LI>Stephen McConnell<A 
+  href=";id=McConnell">?</A>

+  (Apache Avalon) 
+  <LI>James Strachan (Apache Geronimo) </LI></UL>
+<P><STRONG>Section 6 : Incubation Exit Criteria</STRONG> 
+<P>We feel this project should exit the incubator to a TLP using the domain name should the following goals be met: 
+<P><EM>Technical Goals:</EM> 
+  <LI>Clean status with Apaches Continuous Integration System 
+  <LI>Website cross reference to existing Apache literature with respect to 
+  rules and regulations 
+  <LI>At a minimum a beta release and/or a series of Release Candidates for a 
+  directory server and its clients. 
+  <LI>At least one server that complies with <A 
+  href="">[RFC2251]</A> </LI></UL>
+<P><EM>Non-Technical Goals:</EM> 
+  <LI>List presence and monitoring in wider Apache communities 
+  <LI>Website cross reference to existing Apache literarature with respect to 
+  rules and regulations 
+  <LI>Initial integration plan and cooperation with Geronimo, and James 
+  <LI>Member presence on the licensing@apache list 
+  <LI>More Apache or non-Apache committers who are actively modifying source 
+  code </LI></UL>
+<FORM action=apachewiki.cgi method=post><A 
+href="">HomePage</A> | <A


+| <A 


+text of this page</A> | <A 

+other revisions</A><BR>Last edited September 30, 2003 7:59 am <A 

+<INPUT name=search><INPUT type=hidden value=1 name=dosearch> 

View raw message