directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Re: CVS layout
Date Mon, 17 Nov 2003 03:42:48 GMT
Comments inline ...

> 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., Once we have all the code together, we
> may decide to move/refactor some things.

That's great so it's like the atomic peices that can be used to build one I guess with some
provider examples (in memory).  Great!

>   > 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
>   > 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?

Yes these are LDAP client API's and clients.  The PADL clone's would be shared libraries that
enable pam and the nsswitch to use an LDAP server to get to network information.
>   > 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.

Yeah I'm starting to perfer the subproject thing.  Subprojects can also break down things
into their own sub-subprojects et cetera.  I don't understand the "comingling" alternative.
 But no matter I agree with you that we should separate things according to subprojects and
let the subproject manage its own C or Java or a mix of the too.

It's settled for me then +1 to


Let the directory subproject handle its own breakdown with subprojects whether their code
is written in Java, C, Perl or whatever.  Most likely we'll factor out some code in the server
and its common libraries to move non-ldap specific naming code into the naming subproject.
 Then we can just have a dependency on naming APIs.


View raw message