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
convenient.
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
component.
- 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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
