directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: CVS layout
Date Mon, 17 Nov 2003 03:25:23 GMT


aok123@bellsouth.net wrote:
  > Phil,
  >
  > Correct me if I'm wrong but the naming stuff is common JNDI code that
  > could be used with any provider right?  If this is the case then it
  > should stand alone as a peer of the 'ldap' tree as you say.

Yes, it could be used with any provider -- in fact it includes an
in-memory provider.  I agree that it should start at the "ldap" level,
i.e., org.apache.directory.naming. Once we have all the code together, we
may decide to move/refactor some things.

  >
  > I want to take this opportunity to discuss a language independent
  > structure.  Any ideas here?  After a lecture on the APR and apache
  > modules I started drooling at the possibilities on the C side for some
  > of Jeff's ideas.  Basically the APR is a general portable runtime that
  > could be used for both servers and even clients.  It need not be
  > associated with HTTP.  It just happens that it was born out of the
  > common code that was factored out of the server over time.
  >
  > Anyway its good stuff and I think Jeff wanted to build an LDAP cache
  > daemon with nsswitch modules and pam modules for UNIX.  This would be
  > very similar to what Luke Howard has done with PADL here
  > http://www.padl.com/Contents/OpenSourceSoftware.html except it would be
  > free and hopefully work better.  These efforts would also give birth to
  > C based client API's that should in my opinion be based on the APR.

Are you talking about LDAP clients here, or something more general?

  > The httpd team has already started to create a C ldap abstraction layer
  > to do just that.  BTW just to put it on the record, a fellow by the
  > name of Graham Leggett (minfrin@apache.org) who is CC'ed in this email
  > works with the code.  Perhaps Jeff you can establish contact to explore
  > the possibilities of code sharing efforts.
  >
  > So going back to the directory structure, I think we should keep the
  > potential for C code based on the APR in mind.  I don't know the best
  > structure to take this into account.  Perhaps we need to start by
  > creating separate trees for java and c code?  That looks ugly though.
  > Perhaps we can keep it on a functional level then have the project at
  > directory/${sub-prj-name} contain a src/java and/or a src/c directory.
  > That sounds better.

That is an interesting question. My initial instinct is to separate by
subprojects; but I am open to the "comingling" alternative. I am not sure,
however, what that would buy us, since builds would happen independently.

Phil
  >
  > Alex
  >
  >

  >





Mime
View raw message