You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2004/02/01 19:15:23 UTC
svn commit: rev 6408 - in incubator/directory/sitedocs/trunk/sitedocs/xdocs: . images
Author: akarasulu
Date: Sun Feb 1 10:15:23 2004
New Revision: 6408
Added:
incubator/directory/sitedocs/trunk/sitedocs/xdocs/images/asf_logo_wide.gif (contents, props changed)
incubator/directory/sitedocs/trunk/sitedocs/xdocs/project-proposal.html
Modified:
incubator/directory/sitedocs/trunk/sitedocs/xdocs/news.xml
Log:
Added project proposal from wiki that will go away after a while as static
page.
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.
</p>
<p>
- The original proposal can be found <a href=
- "http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject">
+ The original proposal can be found <a href="./project-proposal.html">
here</a>. Thanks to all those that made it happen!
</p>
</subsection>
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 2004
@@ -0,0 +1,360 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<!-- saved from url=(0067)http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject -->
+<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="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage"><IMG
+alt=[Home] src="./images/asf_logo_wide.gif" border=0></A><A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?search=ApacheDirectoryProject">ApacheDirectoryProject</A></H1><A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage">HomePage</A> | <A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges">RecentChanges</A>
+| <A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=editprefs">Preferences</A><BR>
+<HR>
+
+<H1>Proposal for an Apache Directory Project</H1><EM>10 Sept 2003, Alex Karasulu
+(aok123@bellsouth.net) LDAPd Group Founder</EM>
+<HR>
+
+<P>
+<P>
+<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>
+<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
+systems.
+<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
+products.
+<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="http://www.ietf.org/rfc/rfc3377.txt">[RFC 3377]</A> and its associated 8
+RFCs listed below:
+<P>
+<UL>
+ <LI><A href="http://www.ietf.org/rfc/rfc2251.txt">[RFC2251]</A> Lightweight
+ Directory Access Protocol (v3): LDAP on-the-wire protocol
+ <LI><A href="http://www.ietf.org/rfc/rfc2252.txt">[RFC2252]</A> Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions
+ <LI><A href="http://www.ietf.org/rfc/rfc2253.txt">[RFC2253]</A> Lightweight
+ Directory Access Protocol (v3): UTF-8 String Representation of DNs
+ <LI><A href="http://www.ietf.org/rfc/rfc2254.txt">[RFC2254]</A> The String
+ Representation of LDAP Search Filters
+ <LI><A href="http://www.ietf.org/rfc/rfc2255.txt">[RFC2255]</A> The LDAP URL
+ Format
+ <LI><A href="http://www.ietf.org/rfc/rfc2256.txt">[RFC2256]</A> A Summary of
+ the X.500(96) User Schema for use with LDAPv3
+ <LI><A href="http://www.ietf.org/rfc/rfc2829.txt">[RFC2829]</A> Authentication
+ Methods for LDAP
+ <LI><A href="http://www.ietf.org/rfc/rfc2830.txt">[RFC2830]</A> Lightweight
+ Directory Access Protocol (v3): Extension for Transport Layer Security
+</LI></UL>
+<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
+project:
+<P>
+<UL>
+ <LI><A href="http://www.ietf.org/rfc/rfc1274.txt">[RFC1274]</A> The COSINE and
+ Internet X.500 Schema
+ <LI><A href="http://www.faqs.org/rfcs/rfc1804.html">[RFC1804]</A> Schema
+ Publishing in X.500 Directory
+ <LI><A href="http://www.ietf.org/rfc/rfc2079.txt">[RFC2079]</A> Definition of
+ an X.500 Attribute Type and an Object Class to Hold Uniform Resource
+ Identifiers (URIs)
+ <LI><A href="http://www.ietf.org/rfc/rfc2247.txt">[RFC2247]</A> Using Domains
+ in LDAP/X.500 Distinguished Names
+ <LI><A href="http://www.ietf.org/rfc/rfc2293.txt">[RFC2293]</A> Representing
+ Tables and Subtrees in the X.500 Directory
+ <LI><A href="http://www.ietf.org/rfc/rfc2294.txt">[RFC2294]</A> Representing
+ the O/R Address hierarchy in the X.500 Directory Information Tree
+ <LI><A href="http://www.ietf.org/rfc/rfc2307.txt">[RFC2307]</A> An Approach
+ for Using LDAP as a Network Information Service
+ <LI><A href="http://www.ietf.org/rfc/rfc2377.txt">[RFC2377]</A> Naming Plan
+ for Internet Directory-Enabled Applications
+ <LI><A href="http://www.ietf.org/rfc/rfc2587.txt">[RFC2587]</A> Internet X.509
+ Public Key Infrastructure LDAPv2 Schema
+ <LI><A href="http://www.ietf.org/rfc/rfc2589.txt">[RFC2589]</A> Lightweight
+ Directory Access Protocol (v3): Extensions for Dynamic Directory Services
+ <LI><A href="http://www.ietf.org/rfc/rfc2596.txt">[RFC2596]</A> Use of
+ Language Codes in LDAP
+ <LI><A href="http://www.ietf.org/rfc/rfc2649.txt">[RFC2649]</A> An LDAP
+ Control and Schema for Holding Operation Signatures
+ <LI><A href="http://www.ietf.org/rfc/rfc2696.txt">[RFC2696]</A> LDAP Control
+ Extension for Simple Paged Results Manipulation
+ <LI><A href="http://www.ietf.org/rfc/rfc2713.txt">[RFC2713]</A> Schema for
+ Representing Java(tm) Objects in an LDAP Directory
+ <LI><A href="http://www.ietf.org/rfc/rfc2714.txt">[RFC2714]</A> Schema for
+ Representing CORBA Object References in an LDAP Directory
+ <LI><A href="http://www.ietf.org/rfc/rfc2798.txt">[RFC2798]</A> Definition of
+ the inetOrgPerson<A
+ href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=OrgPerson">?</A>
+ LDAP Object Class
+ <LI><A href="http://www.ietf.org/rfc/rfc2829.txt">[RFC2829]</A> Authentication
+ Methods for LDAP
+ <LI><A href="http://www.ietf.org/rfc/rfc2830.txt">[RFC2830]</A> Lightweight
+ Directory Access Protocol (v3): Extension for Transport Layer Security
+ <LI><A href="http://www.ietf.org/rfc/rfc2849.txt">[RFC2849]</A> The LDAP Data
+ Interchange Format (LDIF) - Technical Specification
+ <LI><A href="http://www.ietf.org/rfc/rfc2891.txt">[RFC2891]</A> LDAP Control
+ Extension for Server Side Sorting of Search Results
+ <LI><A href="http://www.ietf.org/rfc/rfc3045.txt">[RFC3045]</A> Storing Vendor
+ Information in the LDAP root DSE
+ <LI><A href="http://www.ietf.org/rfc/rfc3062.txt">[RFC3062]</A> LDAP Password
+ Modify Extended Operation
+ <LI><A href="http://www.ietf.org/rfc/rfc3088.txt">[RFC3088]</A> OpenLDAP<A
+ href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=OpenLDAP">?</A>
+ Root Service An experimental LDAP referral service
+ <LI><A href="http://www.ietf.org/rfc/rfc3112.txt">[RFC3112]</A> LDAP
+ Authentication Password Schema
+ <LI><A href="http://www.ietf.org/rfc/rfc3296.txt">[RFC3296]</A> Named
+ Subordinate References in Lightweight Directory Access Protocol (LDAP)
+ Directories
+ <LI><A href="http://www.ietf.org/rfc/rfc3383.txt">[RFC3383]</A> Internet
+ Assigned Numbers Authority (IANA) considerations for the Lightweight Directory
+ Access Protocol (LDAP) </LI></UL>
+<P>
+<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 below
+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
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=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
+server.
+<P>We see the Apache Directory Project as a separate project to existing Apache
+projects, serving several roles
+<UL>
+ <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="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ApacheDirectoryProject/Decoding">?</A>
+ Library </LI></UL>
+<P>
+<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 code
+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 are
+currently paid to work on the Directory Project.
+<P><EM>No ties to other Apache products:</EM> The Apache Directory Project is
+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>
+<P><STRONG>Section 1 : Scope of the Project</STRONG>
+<P>There are multiple goals for this Apache project:
+<P>
+<UL>
+ <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.
+</LI></UL>
+<P>
+<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="http://sourceforge.net/projects/ldapd">[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
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ApacheDirectoryProject/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>
+<P>
+<UL>
+ <LI>directory-dev@incubator.apache.org </LI></UL>
+<P><EM>Section 3.2 : CVS Repositories</EM>
+<P>
+<UL>
+ <LI>incubator-directory </LI></UL>
+<P><EM>Section 3.3 : Bugzilla or (preferably) Jira</EM>
+<P>
+<UL>
+ <LI>directory </LI></UL>
+<P>
+<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:
+<P>
+<UL>
+ <LI>Alex Karasulu
+ <LI>Phil Steitz
+ <LI>Robb Penoyer
+ <LI>Noel Bergman
+ <LI>Jeff Machols
+ <LI>Henri Yandell
+ <LI>Wes McKean<A
+ href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=McKean">?</A>
+ </LI></UL>
+<P>
+<P><STRONG>Section 5 : Apache Sponsoring Individuals</STRONG>
+<P>
+<UL>
+ <LI>Nicola Ken Barozzi (Apache Incubator)
+ <LI>Noel J. Bergman (Apache James)
+ <LI>Henri Yandell (Jakarta Commons Naming)
+ <LI>Stephen McConnell<A
+ href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=McConnell">?</A>
+ (Apache Avalon)
+ <LI>James Strachan (Apache Geronimo) </LI></UL>
+<P>
+<P><STRONG>Section 6 : Incubation Exit Criteria</STRONG>
+<P>We feel this project should exit the incubator to a TLP using the domain name
+directory.apache.org should the following goals be met:
+<P><EM>Technical Goals:</EM>
+<P>
+<UL>
+ <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="http://www.ietf.org/rfc/rfc2251.txt">[RFC2251]</A> </LI></UL>
+<P><EM>Non-Technical Goals:</EM>
+<P>
+<UL>
+ <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>
+<HR>
+
+<FORM action=apachewiki.cgi method=post><A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?HomePage">HomePage</A> | <A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?RecentChanges">RecentChanges</A>
+| <A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=editprefs">Preferences</A><BR><A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=ApacheDirectoryProject">Edit
+text of this page</A> | <A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=history&id=ApacheDirectoryProject">View
+other revisions</A><BR>Last edited September 30, 2003 7:59 am <A
+href="http://nagoya.apache.org/wiki/apachewiki.cgi?action=browse&diff=1&id=ApacheDirectoryProject">(diff)</A><BR>Search:
+<INPUT name=search><INPUT type=hidden value=1 name=dosearch>
+</FORM></BODY></HTML>