[API] Status

2015-04-29 Thread Emmanuel Lécharny
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

2015-04-29 Thread Emmanuel Lécharny
Le 29/04/15 15:54, Shawn McKinney a écrit :

 On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny elecha...@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 elecha...@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 elecha...@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 elecha...@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

2015-04-29 Thread Shawn McKinney

 On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny elecha...@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 elecha...@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 elecha...@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 elecha...@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 elecha...@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 elecha...@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
smckin...@apache.org