directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Getting a sense of the subproject structure
Date Fri, 10 Dec 2004 19:24:46 GMT
Berin Loritsch wrote:

> <rant type="good natured">
>  The project structure for directory is mixed up, and there isn't a 
> clear picture of how they relate.
>  Of course, this is more true the lower down the stack you go (which 
> is where I started working).
>  There is some stuff in "snickers" and other stuff in "ldap" that 
> seems to cross relate.
> </rant>
>
:)

> Well, this is an incubator project, and we have something that does 
> work.  I don't like work for
> work's sake, but at the same time I also like a sense of order and 
> layering to APIs that are for
> the most part intuitive.
>
> The way things are currently structured, I would assume the following:
>
> seda - lowest level network only layer
> snickers/ldap - protocol provider for integrating with the ldap server

Let me clarify this some more so there is a distinction here between 
what ldap is and snickers is as far as projects go. 

Snickers is an ASN.1 runtime and stub compiler.  It currently supports 
BER/DER/CER codecs.  We want to add PER and XER at some point perhaps.  
Snickers is independent of LDAP and should not have deps on it.  
Unfortunately my test cases use LDAP PDU's to test Snickers' BER 
functionality :(. I'll pull this stuff out soon.  I need to organize my 
thoughts on some major cleanups here in Snickers both as far as the 
project organization is concerned and the code is concerned.  This I 
will do in an intense refactoring within the 0.3.0 branch.  0.3.0 will 
be in the trunk right after 0.2.0 is out and pushed into a maintenance 
branch in svn.

The ldap project is for a common LDAP library that can be used to build 
LDAP clients and servers.  Eve uses it and so does the clients project 
which is kinda dead at the moment.  The goal is to build JNDI LDAP 
client providers, and that LDAP Client API using this stuff too.

> naming - JNDI provider for working with embedded or networked ldap server
> eve - the LDAP server on steroids
> kerberos - the kerberos authentication protocol
>
yep

> I am not too certain on "janus" and "rms" what they would be.
>
Janus is a AAA API not really a protocol impl though it might get there. 

RMS is a non-standard API for AAA and more - a really nutty idea I had 
but am no longer persuing it at the moment.  It will be sandboxed or 
just left as is without putting it on the directory site.  I'll pull it 
out shortly before updating the sitedocs.

> I would like to set up some modifications to the project heirarchy:
>
> protocol-api - the core interfaces for networking/protocol providers

Ok this is analogous to what avalon framework used to be for generic 
containers but for networking frameworks.  Makes sense to me.

> network - the place for the new seda and mina

yeah agreed

> ldap? - common code for ldap clients and servers
> providers - where protocol providers are located

Good idea Enrique kept asking for this.

Alex

Mime
View raw message