directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Project reorganization proposal
Date Fri, 03 Apr 2009 18:45:41 GMT
Hi all,

On Fri, Apr 3, 2009 at 1:44 PM, Emmanuel Lecharny <>wrote:

> We currently have a few 'top level' projects :
> * Apache DS 1.0
> * Apache DS 1.5
> * Studio
> * Triplesec
> Those are the projects a user can see on the web site. It's maybe time to
> change that a bit. We could have something like :
> * LDAP Client-API
> * ApacheDS
>  o ADS 1.0 (will die some day ...)
>  o ADS 1.5 (won't survive 2.0)
>  o ADS 2.0 (soon !)
> * Studio
> * Kerberos
> * Triplesec

I was thinking of offlining tsec but I think after 2.0 it will be easier
than ever to resusitate her.  +1 to a Kerberos project to attract more
talent and users specifically into Kerberos and clients for Kerberos.

> - The LDAP client-API will be a new project, marked as 'WiP' (Work in
> Progress).
> - Kerberos may deserves its own project at some point, if we have aenough
> committers working on it. Obviously will be marked as WiP. The big advantage
> wpuld be to potentially bring more visibility to this project
> - Triplesec should also be marked as WiP, or even better, 'prototype'.


A year from today we can re-evaluate what to do with projects whose status
have not yet changed.

> Now, let's think about the inner modules. The new client-API will contain a
> lot of shared code. Here are the elements I see can be part of the
> client-API :
> o Entry
> o Connection

> o LDIF

Would like to leave LDIF handling code in shared.  I don't know if this is a
good idea though.  This is not really client related nor server related.
Both the client and the server will use this.

> o DSML

> o DN
> o RDN
> o AttributeTypeAndValue
> o ObjectClass
> o AttributeType
> o Syntax
> o MatchingRule
> o Message (all the LDAP requests)

I think all of these have as much a reason to be in shared as they do in the
client package.  Also I think that you might want to have some simpler API
in the client then just taking what's in shared and pushing it into client.
Reason being is most of this stuff has been crafted for server use although
it certainly can be used for the client.

I just think we're better off just creating what seems to be a redundant set
of classes for client but just keeping it all really simple and specialized
rather than trying to make something work for more than one scenario.


View raw message