> That isn't the question I was asking. If someone else comes to Apache > and says they want to start an LDAP server project using, for example, > the Netscape code base (C++, I think) and another comes in wanting to > establish a Python library for builtin calls to LDAP, should the ASF > direct those projects to this same group or to their own projects?
Let's work with an example. If PerlLDAP were a candidate for incubation and joined the incubator it would probably exit into a directory subproject. So yes it would become part of the directory project. Another example would be the PADL name server switch module and pam module written in C here: http://www.padl.com They would also go under the directory project. We should be protocol centric and language-agnostic. BTW, I think the netscape stuff is C, it branched of the original UMich server written in C by Tim Howes et. al. > I have no problem with protocol-centric projects, and no problem with > language-centric projects, but I do have a problem with protocol-centric > projects that assume one implementation language is "best". Those types > of projects create failure conditions that are very messy from the > board's POV. So, if the project is going to be language-agnostic, then > I want that written into the charter and growth anticipated. If not, > then I want that written into the charter and a different name given > to this project. Doesn't that make sense? Different implementations will have different advantages. No one implementation surpasses another and I apologize if the proposal came off that way. Right now a Java based server is what we have. Plus people are excited that Java has grown up enough to handle the endeavor finally ;-). Let's go ahead and put the language-agnostic clause into the charter and work together to make the new project a one stop shop for anything solely oriented with a directory. Let me know if that clarifies some of your concerns. Sincerely, Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
