On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
Hi all,

I'd like to share a few discussions I've had these days with Stefan S. and Emmanuel.

I was talking to Stefan on IM on friday and we were wondering how we could improve the LDAP Browser and the Connection plugin.
Stefan would like to get rid of the use of JNDI in Studio because of the problems we have with this API.
He enumerated a number of benefits to using a client "LDAP protocol" oriented connection wrapper instead of the JNDI one:
  • Direct access to the LDAP protocol
  • Direct access to the result codes (we now must parse the NamingException message)
  • Access to the message ID
  • Network settings (timeouts, etc.)
  • Threading
  • Referral handling (JNDI tries to be clever to manage referrals internally, but we want to manage them manually)
  • LdapDN handling is poor in JNDI
  • You have to set weird environment variables to make it working properly
  • JNDI has no cancel operation, you must use ctx.close() to cancel an operation
We were wondering if the "Codec" classes in Shared would allow us to do such a thing.

Great because we need this API for virtualization and possibly delegated authentication as well within the server.

In the afternoon, I talked about this with Emmanuel who told me that most of the classes of Shared could be reused easily but also that we might need to add new ones (for SSL/SASL client authentication, or controls/extensions for example).


He advised me to ask on the ML, so we can discuss things further and see what can be done with what we have today, and what we nee to work on to build this low-level LDAP protocol connection wrapper.


I think we're talking about writing a modern LDAP API similar in nature to the Netscape API to replace JNDI.  JNDI could use this API if it wanted to as well but this is a less abstract, more specific API for LDAP.  The more specific the API is the less surface area it will have.  The better it is to comprehend and test.

I like the idea of doing this and leveraging the Entry API Emmanuel has written to do so.  It will be nice to have it align with things we use in Shared to save us the head ache and overhead of converting from one object type to another for example.

This is value.  If you guys decide to embark on it then I would like to help and get involved too.

We might have some issues with the codec but we can fix that as we go.