You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2017/08/03 12:03:48 UTC

Ldap API 2.0 roadmap

Hi guys,


I didn't had time last week-end to post this mail.

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.


Beside this effort, I started to work on a branch
(http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
which was a refactoring of the Value class, in order to simplify what we
had in 1.0. The rational was to get some major errors being fixed in
ApacheDS (mainly related to some special chars being mis-handled in
DNs). The consequences are huge in term of performances (20% faster),
but impacts the projects using this API.


At this point, I'd like to suggest we start with a 2.0 because of those
API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
the branch, and I also have a branch for Apacheds which relies on the
API branch. What remains to be done is to switch to this branch for Studio.


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 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.


I'd like to have your opinion about those proposed changes, before
starting an official vote.


Many thanks !


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org


Re: Ldap API 2.0 roadmap

Posted by Emmanuel Lécharny <el...@gmail.com>.

Le 03/08/2017 à 15:05, Shawn McKinney a écrit :
>
>> On Aug 3, 2017, at 7:03 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>>
>> Beside this effort, I started to work on a branch
>> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
>> which was a refactoring of the Value class, in order to simplify what we
>> had in 1.0. The rational was to get some major errors being fixed in
>> ApacheDS (mainly related to some special chars being mis-handled in
>> DNs). The consequences are huge in term of performances (20% faster),
>> but impacts the projects using this API.
>>
>>
>> At this point, I'd like to suggest we start with a 2.0 because of those
>> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
>> the branch, and I also have a branch for Apacheds which relies on the
>> API branch. What remains to be done is to switch to this branch for Studio.
>>
>> 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 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.
>>
>> I'd like to have your opinion about those proposed changes, before
>> starting an official vote.
>>
> Seems a little strange to have a 2.0 this close to a 1.0 release but in the end the version doesn’t matter all that much.  The main thing is we keep forward progress so…

Well, I think it conveys a message : it's alive ! Once upon a time, OSS
was very conservative, and projects were moving from X to X+1 with
extreme caution (httpd, etc). Then Chrome changed the game with its fast
incremental version releases, and Fireforx followd, and now, many other
projects do the same.

I do think it's easier for people to follow up when the major is
changing rather than going on with somethig that remains teh same for
years...

But that may be just me.

Otherwise, considering teh API changes, we can't make it a minor (ie
1.1), so 2.0 is quite necesary.

Btw, 1.0 will be maintained, so we are likey to have a 1.0.1 and some
other versions later o (with Java 7 support, of course).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org


Re: Ldap API 2.0 roadmap

Posted by Shawn McKinney <sm...@apache.org>.

> On Aug 3, 2017, at 7:03 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> I didn't had time last week-end to post this mail.
> 
> 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.

No it’s not perfect but what software library is?  It’s a very good and stable API that is approaching 1M downloads a month via maven, meaning it has traction.  

Congrats on getting it this far.

> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> 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 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.
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 

Seems a little strange to have a 2.0 this close to a 1.0 release but in the end the version doesn’t matter all that much.  The main thing is we keep forward progress so…

+1 on that, move to Java 8 and GIT.

Thanks,
Shawn



Re: Ldap API 2.0 roadmap

Posted by Emmanuel Lécharny <el...@gmail.com>.

Le 04/08/2017 à 07:03, Stefan Seelmann a écrit :
> +1 just move forward.
>
> The only thought I have is to do a Studio release with current ApacheDS
> and API version, I wanted to do since weeks it but didn't find the time
> and won't have time in the next 2 weeks either.

I can create a branch for Studio supporting the new API and ApacheDS
version, that would make sense.

Whenever you are ready for a release of Studio is fine. In any case, the
studio branch I would create won't be ready in the  next two weeks ;-)


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org


Re: Ldap API 2.0 roadmap

Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
+1 just move forward.

The only thought I have is to do a Studio release with current ApacheDS
and API version, I wanted to do since weeks it but didn't find the time
and won't have time in the next 2 weeks either.

Kind Regards,
Stefan


On 08/03/2017 02:03 PM, Emmanuel Lécharny wrote:
> Hi guys,
> 
> 
> I didn't had time last week-end to post this mail.
> 
> 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.
> 
> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> 
> 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 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.
> 
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 
> 
> Many thanks !
> 
> 


Re: Ldap API 2.0 roadmap

Posted by "Zheng, Kai" <ka...@intel.com>.
Sounds exciting and great move! Any more legacy to get rid of by the chance?

Sent from iPhone

> 在 2017年8月3日,20:04,Emmanuel Lécharny <el...@gmail.com> 写道:
> 
> Hi guys,
> 
> 
> I didn't had time last week-end to post this mail.
> 
> 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.
> 
> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> 
> 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 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.
> 
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 
> 
> Many thanks !
> 
> 
> -- 
> Emmanuel Lecharny
> 
> Symas.com
> directory.apache.org
> 

Re: Ldap API 2.0 roadmap

Posted by Emmanuel Lécharny <el...@gmail.com>.

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

Symas.com
directory.apache.org


Re: Ldap API 2.0 roadmap

Posted by Radovan Semancik <ra...@evolveum.com>.
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.

-- 
Radovan Semancik
Software Architect
evolveum.com