directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: CVS layout
Date Mon, 17 Nov 2003 07:24:04 GMT


aok123@bellsouth.net wrote:

>Comments inline ...
>
>  
>
>>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.
>>    
>>
>
>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
>>  > 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?
>>    
>>
>
>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
>
>directory/ldap
>directory/naming
>
>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.
>

My preference would be to be able to checkout a langauge specific tree.

For example:

   directory/java
   directory/c

 From the root of /java I should be able to build using langause 
specific tools and not be concerned with artifacts from another 
language.  Things like commits as the top level (i.e. directoriy/java 
should be specific to a langauge).

However, It's not so clear to what the product breakout is at the top 
level - perhaps it is better to do:

   directory/ldap/java
                 /c

Can anyone provide a summary of the main projects (i.e. ldap,...).

Stephen.



>Alex 
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|





Mime
View raw message