Nicola, Forgive me but I thought I'd change the subject of the email and perhaps if you would like we could move it to a more appropriate mailing list.
"How does it sound?" You ask, well it all sounds good to me. Avalon is a great fit and pathway immediately out of the incubator since the server is an Avalon based server. We should fell right at home with it there and think several Avalon folks could help join the effort. So I guess the sponsoring PMC we would need to contact would be Avalon's PMC. Seeing as how you're the Avalon PMC Chair would you begin the process of sponsoring LDAPd? I don't know what this entails on your side but I guess its a PMC vote to sponsor right? I just have a few questions regarding the process and structure of things to come. First you will be asking the incubator to add us. What will determine the graduation into Avalon as an Avalon subproject? I'm guessing the formation of a community around the OS project in line with the Apache Way is the goal. Now LDAPd has several CVS projects segmenting the code into logical areas. For example there is an ldapd-common for common client and server code. There is a ldapd-client which contains clients and client specific library code. Then there is ldapd-server which contains the blocks of the ldap server in a package structure reflecting the blocks. Also there are CVS modules for each type of backend like modjdbm, modjdbc etcetera. My question is how would all these different repositories need to be managed would we merge them into one or can they stay separate. I would rather keep them separate since some people will have access to clients and others will be server side and library developers. This is probably why I eventually would like to see this become a top level project like James. Please don't misconstrue my LDAP vision for sensibility - we would certainly need incubation time and a good amount of time maturing under Avalon before reaching such a production grade state. I'm just looking forward to a future where I can go to one place to do my Java LDAP shopping so to speak just like the way I can do it for Java Servlets, and Java Mail today at Apache. I know all the guys at LDAPd would be fine with the move I would still need to run it by them and take a count. It's the right thing to do. What else would I need to do to begin the process if the PMC approves the sponsorship? Alex > > From: Nicola Ken Barozzi <[EMAIL PROTECTED]> > Date: 2003/07/14 Mon AM 04:04:52 EDT > To: [EMAIL PROTECTED] > Subject: Re: Silk status > > > > [EMAIL PROTECTED] wrote, On 11/07/2003 18.43: > > >>I do encourage your group to propose ldapd for the ASF. I don't know if it > >>would best be an Incubator project or Jakarta (Commons). Personally, I'm > > > > I'm working with a few of the guys right now to rethink the design of LDAPd. > > We're trying now to enable LDAPd with a catelog similar to Oracle's where actual > > tables are used to manage other tables. Like Oracle we will be using a default > > backend (a directory context) to store this catelog information that can be > > manipulated by admins usign the LDAP protocol. Anyway this default backend will > > make the injection of orthogonal services like authorization, trigger support > > etcetera easier to implement. For the time being the server is close to RFC2251 > > but needs significant work. Although labeled alpha it performs like a beta and > > its just missing a few of the bells and whistles: the access and protocol is solid. > > > > I and others have thought about joining ASF to have more proficient ASF quality > > developers on board the project. LDAPd is very nicely aligned with several ASF > > projects: Avalon, Commons, Slide, James and even Tomcat. Do you think joining the > > ASF will help progress LDAPd? I and the others would be up for it if I have > > support from you guys on the Avalon team. Do we have your (the Avalon team's) > > support/sponsorship to join? > > You have mine. > > > Now in terms of Jakarta verse the incubator I don't have a preference other than > > what will help both parties come along. Looking at the direction of Apache in > > general and some of the code in LDAPd I see some very interesting things we can do. > > As a member if the incubator: any project that enters Apache must pass > through the Incubator. The point is about where it will go after > incubation, if under another project or as it's own top level project. > > > First I see db.apache.org and so I'm thinking ldap.apache.org. I guess this is a > > natural progression after going through perhaps some incubation. The code used in > > LDAPd's default backend is very conducive for an embedable RDBMS. In fact we can > > build out a dbcore package in Jakarta's Commons supporting BTrees and composite > > structures like indices and tables etcetera built on them. This package can then > > be leveraged directly by databases in ldap.apache.org and db.apache.org and by > > certain Avalon components that may be conjured up. Both ldap.apache.org and > > db.apache.org can be one stop OS shoping centers for you database and LDAP needs. > > What do you and the Avalon folks think about these ideas? > > I would really like to see the project land at Apache. > > I would propose you that you find a sponsoring PMC that will ask the > Incubator for you to enter Apache. Then, after incubation, your project > would be a sub-project of Avalon. When it will become big enough, we can > decide to make it get out of Avalon ond reside top-level as > ldap.apache.org. This is what most other projects have done: Avalon was > under Jakarta, James too, Ant the same, Cocoon under xml.apache.org, etc. > > What does this sound like? :-) > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
