Le 29/04/15 15:54, Shawn McKinney a écrit : > > On Apr 29, 2015, at 3:19 AM, Emmanuel Lécharny <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 :/
