Noel take a look at my replies to your comments in context below: > 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? 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. 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? > hoping to start work next week on getting JNDI into James, and will want to > follow up with you on using ldapd as we discussed earlier. Is ldapd in > shape to do that? Let me know and I'll be there to help with any of your needs. Sure its ready for testing and integration but it is already designed for leveraging legacy JNDI code in mind. If you remember the backend apparatus is completely detachable from the network protocol server front-end. A server-side JNDI provider is used to transparently access the backend. Code using JNDI can be local or remote to the LDAP backend. Also note that you can go ahead and use JNDI with any LDAP server for now in a 2-tier configuration. Once LDAPd is ready it can be embedded into James using the server-side JNDI provider without requiring code changes; only the JNDI context factory properties would change. So yes LDAP can be used today although not recommended for anything remotely production grade. > > > we have been debating like using NIO or Matt Welsh's native apis. > > If we use Matt's stuff then we loose the compile once run anywhere. > > If we use NIO then we don't have ssl. So there are many tradeoffs. > > I recommend that you (a) support nio, and (b) adopt the correct push > programming pattern so that it doesn't matter package is supplying data to > your handlers. That is something we'll be doing with James as well, > although it is not at the front of the priority queue. As you note, it is > absolutely vital when supporting large numbers of connections. > Right I agree with you fully the work in the form of events could come from anywhere and dependencies should not be imposed. Right I was bending towards NIO myself. These are the kinds of discussions I want to have with people from ASF so I know that LDAPd is at least heading in the right direction. I would go with NIO because SSL introduction is inevitable and NIO is std java which enables the run anywhere paradigm. rnet applications. > > With respect to SSL, that is a known issue. I haven't spoken with Mark in a > while, but I believe that SSL was planned for the 1.5 release. That's great - I tried to confirm this myself but could not find references to SSL intro at java.sun.com or in any of the associated JCPs. Could we find this out? Talk to you soon, Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
