[API] Status

[Emmanuel Lécharny <el...@gmail.com>]

Hi guys,

as we are currently voting the 1.0.0-M30 release of teh LDAP API, I'd
like to provide a quick status. The idea is to know what's missing to
get a first RC, and I do think we are not that far.

What are the critical features we need to add in the RC ? Here is a
short list :

- Support of referral chasing (DIRAPI-61, DIRAPI-179).

This is not that complex to add, I would say it's a 2/3 days work, max
(tests included). The idea is to gather all the referrals response we
get, then when we are done with the normal entries, start chasing the
referrals one by one. As we may get more referrals, we have to take care
of potential cycles, and hops (cycle must be detected, and the number of
hops must be limited).

- Make the API threadsafe (DIRAPI-237)

This is a bit complex, as we have to secure the shared structure we use
to process the incoming responses. I would say that 5 days of work
should be enough for this task, but tests might be a bit complex to
prove we are correct.

- StartTLS hostname verification (DIRAPI-69 and DIRAPI-72
<https://issues.apache.org/jira/browse/DIRAPI-72>)

Probably something we want to add into the API before the RC. It's
convenient.

- OpenLDAP schema parsing (DIRAPI-154)

Radovan is working on it. I can give a hand if needed...

- TLS closure support (DIRAPI-136)

We don't yet support the TLS closure. Basically, once TLS is started, we
can just close the connection. Not ultra critical, but really convenient
to have !

- Exceptions (DIRAPI-116)

It would be very cool to review the Exceptions being thrown by the API
methods, to make them consistent, before cutting a RC, otherwise we will
be stuck with the wrong exceptions for a very long time.

- Documentation

There are a lot of missing Javadoc, and the web site *has* to be updated...

So, we are not that far, but still, there is work to do. I think we can
get a RC out in one month of work. I also think that it would be
valuable to get it out soon, it's more than 5 years we are working on
the API, and it's already stable enough to be used in production, we are
just hit by what I call the 'Debian syndrom'...

Thoughs ?

Re: [API] Status

[Emmanuel Lécharny <el...@gmail.com>]

Le 29/04/15 15:54, Shawn McKinney a écrit :
>
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> - Make the API threadsafe (DIRAPI-237)
>
> This is a bit complex, as we have to secure the shared structure we use
> to process the incoming responses. I would say that 5 days of work
> should be enough for this task, but tests might be a bit complex to
> prove we are correct.
>
>
> +0  Don’t understand the value proposition.  Best practice is to pool the connections, thus negating the need for thread safety.

Not exactly enough. Typically, in Studio, you may spawn many threads
using one single connection, and send many concurrent searches.

>
>> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>>
>> - OpenLDAP schema parsing (DIRAPI-154)
>>
>> Radovan is working on it. I can give a hand if needed...
>>
> Need to understand the use cases before I comment further.
Simply being able to read a full OpenLDAP server schema, and be able to
use the SchemaManager. There are not a lot of differences between
OpenLDAP and ApacheDS schema, except that OpenLDAP schema may use some
special extensions (X-<blah>) and OID names (like OLcfgGlAt:31) that we
currently don't support.

>
>> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>
>> - TLS closure support (DIRAPI-136)
>>
>> We don't yet support the TLS closure. Basically, once TLS is started, we
>> can just close the connection. Not ultra critical, but really convenient
>> to have !
>>
> Again, don’t understand the use case.

When you send a startTLS extended operation, the connection negociate an
encryption scheme and then every requests and responses are being sent
encrypted, over the standard LDAP port. StartTLS must be used in place
of LDAPS, which is considered as deprecated. The thing is that yu should
be able to switch back to a non-encrypted mode when you send a TLS
closure, which should not close the connection.
>
>
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>
> - Documentation
>
> There are a lot of missing Javadoc, and the web site *has* to be updated...
>
> So, we are not that far, but still, there is work to do. I think we can
> get a RC out in one month of work. I also think that it would be
> valuable to get it out soon, it's more than 5 years we are working on
> the API, and it's already stable enough to be used in production, we are
> just hit by what I call the 'Debian syndrom'...
>
> Thoughs ?
>
> +1 One of my pet peeves - poor documentation.  Such a herculean task, difficult to know where to start.  Perhaps we can divide and conquer?

We already have a TOC for the API, it's just that most of the content is
empty :/

Re: [API] Status

[Shawn McKinney <sm...@apache.org>]

> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> Hi guys,
> 
> as we are currently voting the 1.0.0-M30 release of teh LDAP API, I'd
> like to provide a quick status. The idea is to know what's missing to
> get a first RC, and I do think we are not that far.
> 
> What are the critical features we need to add in the RC ? Here is a
> short list :
> 
> - Support of referral chasing (DIRAPI-61, DIRAPI-179).
> 
> This is not that complex to add, I would say it's a 2/3 days work, max
> (tests included). The idea is to gather all the referrals response we
> get, then when we are done with the normal entries, start chasing the
> referrals one by one. As we may get more referrals, we have to take care
> of potential cycles, and hops (cycle must be detected, and the number of
> hops must be limited).
> 

+1  I had a conversation with Lucas on this topic at ACNA earlier in the month.  He convinced me then of its value.

> 
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> - Make the API threadsafe (DIRAPI-237)
> 
> This is a bit complex, as we have to secure the shared structure we use
> to process the incoming responses. I would say that 5 days of work
> should be enough for this task, but tests might be a bit complex to
> prove we are correct.
> 
> 

+0  Don’t understand the value proposition.  Best practice is to pool the connections, thus negating the need for thread safety.

> 
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> 
> - OpenLDAP schema parsing (DIRAPI-154)
> 
> Radovan is working on it. I can give a hand if needed...
> 

Need to understand the use cases before I comment further.

> 
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> - TLS closure support (DIRAPI-136)
> 
> We don't yet support the TLS closure. Basically, once TLS is started, we
> can just close the connection. Not ultra critical, but really convenient
> to have !
> 

Again, don’t understand the use case.

> 
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> 
> - Exceptions (DIRAPI-116)
> 
> It would be very cool to review the Exceptions being thrown by the API
> methods, to make them consistent, before cutting a RC, otherwise we will
> be stuck with the wrong exceptions for a very long time.
> 

+1 Crucial for stable APIs as clients rely on these.

> 
> 
> On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> 
> 
> - Documentation
> 
> There are a lot of missing Javadoc, and the web site *has* to be updated...
> 
> So, we are not that far, but still, there is work to do. I think we can
> get a RC out in one month of work. I also think that it would be
> valuable to get it out soon, it's more than 5 years we are working on
> the API, and it's already stable enough to be used in production, we are
> just hit by what I call the 'Debian syndrom'...
> 
> Thoughs ?
> 

+1 One of my pet peeves - poor documentation.  Such a herculean task, difficult to know where to start.  Perhaps we can divide and conquer?

Shawn
smckinney@apache.org