directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Moving DIRSHARED into DIRAPI, take 2
Date Tue, 24 Jan 2012 13:33:07 GMT
Hi guys,

last summer, a [VOTE] has been started about merging DIRShARED with 
DIRAPI. We have had 5 +1 votes for it, but the operation was not done, 
because we didn't decide if API should be moved to SHARED or the opposite.

I understand that there are some concerns :
- we may lose some track in the code/commit to specific references to 
the removed space
- API is more than just SHARED

The first concern will be mitigated if we simply move opened issues from 
SHARED to API, laving the old SHARED issues in SHARED. In other words, 
we will keep SHARED as a space, but it won't accept anymore issues.

The second concern is more interesting, IMO. The pb here is that the API 
is a bit more than SHARED. SHARED was supposed to store all the elements 
common to Studio and ADS (plus some side projects like TripleSec and 
Kerberos). If we remove SHARED to only keep API, then we will cover more 
than just what is in common, but also some specific parts that may not 
be interesting for kerberos, for instance.

However, right now, I think it's the right move, not perfect but 

I just had to move all the opened issues from shared 1.0.0-M9 to 
1.0.0-M10, and closed the revision, one week after the release for API 
has been done. It will occur again, as we don't anymore check SHARED 
before we vote a release.

In a near future, we may decide to split the API in two parts :
- a common set of classes, namely SHARED (could have been commons-ldap 
too), whch could be used by the server, studio, kerberos or whatever 
- a specific set of clesses for the LDAP-API.

However, I'm not sure this make a lot of sense, as the server uses the 
LDAP-API for replication, and Kerberos is not yet a separate project, 
plus Studio is using the LDAP-API fully.

Thoughts ?

Emmanuel L├ęcharny

View raw message