Hi guys,
comments inline
Alex Karasulu wrote:
Hi,
On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]>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.
+1
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.
yep.
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.
Yep.
I would also add that there are a few things around there which could be
looked at :
https://opends.dev.java.net/public/standards/draft-ietf-ldapext-ldap-java-api.txt
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
www.iktek.com
directory.apache.org
