directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Studio] [Shared] New low-level LDAP Protocol Connection Wrapper for Studio using the Shared classes?
Date Mon, 08 Sep 2008 14:51:46 GMT
Hi guys,

comments inline

Alex Karasulu wrote:
> Hi,
> On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <>wrote:
>> Hi all,
>> I'd like to share a few discussions I've had these days with Stefan S. and
>> Emmanuel.
We also have some discussion with Alex, and also Howard Chu during the 
last LdapCon in Köln last year, about a new Ldap API. Not to mention the 
convos we had with soem Sun peeps 2 years ago about a new JNDI-v2.

It's cool to see that we are having this convo again !
>> 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
plus poor Controls handling, poor Extended Operation handling, messy 
semantic for operation (JNDI Bind != LDAP Bind)...
>> We were wondering if the "Codec" classes in Shared would allow us to do
>> such a thing.
Not pristine, but this is certainly a part of it. You have to combine it 
with the Entry API, a network layer, plus certainly clean these codec 
classes ;)
>> 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).
We must also make it easy to plug extensions and controls. ATM, 
encoding/decoding controls is, to say the least, a PITA. Sadly, I don't 
see how this could be done easily, but we must at least ease the 
integration of a new codec for a control or an extended operation.
>> 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.
>> WDYT?
> 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.
Certainly ! And will help also to get more people around this portion of 
the code.
> This is value.  If you guys decide to embark on it then I would like to help
> and get involved too.
me too.
> We might have some issues with the codec but we can fix that as we go.

I would also add that there are a few things around there which could be 
looked at :

and some discussion with the OpenLdap guys would be very interesting.

Thanks for bringing this subject back on the table !
> Alex

cordialement, regards,
Emmanuel Lécharny

View raw message