directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Ldap API 2.0 roadmap
Date Thu, 03 Aug 2017 17:05:25 GMT

Le 03/08/2017 à 18:43, Radovan Semancik a écrit :
> On 08/03/2017 02:03 PM, Emmanuel Lécharny wrote:
>> We have released the Apache LDAP API 1.0 a few weeks ago. This was a
>> great acomplishment, after years of efforts. It was not perfect, but
>> still, 'good enough' is probably the correct description.
> I would say this is more than a correct observation :-)
>> ... So let's thing bigger : If we go for a 2.0, I also suggest we
>> move to
>> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
>> also switch to Java 8 and will use this API 2.0 in M25, and teh next
>> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
> I completely support this proposal.
>> I would also suggest we switch to git for the API, now that 1.0 is out.
>> SVN is outdated, and it's quite an anchor for us anyway (I have to use
>> svn *and* git daily, it makes things more complex...). Nor sure we
>> should'nt move to git for all teh projects, but startng wih teh API
>> sounds reasonable atm. In any case, I'll write another mail for this
>> change.
> Yes, yes, yes! Then sooner the better.
> I have few more things to add:
> I would like to personally work on the schema error handling and
> reporting. The API currently logs every schema problem as an error -
> even if it can live with the situation. This is really annoying when
> using the API with dirty LDAP servers. The logs are flooded with error
> messages and there is no easy way how to get rid of them. So I would
> like to improve this part of code and make error reporting
> optional/configurable/pluggable.
> But ... it is likely that any reasonable changes in the code are going
> to break compatibility with API 1.0. Unless we want to maintain very
> ugly and complex compatibility code. Therefore I suggest that we do
> NOT stick to a strict API compatibility between 1.0 and 2.0. This is
> not a problem for me, as I can quickly adapt my client application.
> But I'm aware that it might be a problem for other people. Therefore I
> would like to know opinions of the community regarding API 1.0->2.0
> compatibility.

2.0 is not guarentiing an API compatibility with 1.0. However, I think
we ought to write down a migration guide.

So I think we can bork everything we want, up to a point of course.

Emmanuel Lecharny

View raw message