directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Betts <ch...@pegacat.com>
Subject Re: Client library
Date Wed, 03 Aug 2005 01:22:30 GMT
my 2c ... :-)

The JXplorer LDAP client has been using JNDI since 1999, and it  
hasn't been an entirely pleasant experience.  As Marc and others have  
pointed out, JNDI uses a complex federation architecture combined  
with confusing terminology that makes it difficult to use for 'simple  
ldap operations (tm)'.  JXplorer solved the problem by building a  
simplifying abstraction layer on top of JNDI, which also allowed for  
various JNDI bugs to be fixed in a single place.

However JNDI has come a long way in the last six years, and I don't  
think there are any serious bugs in the core code any more.  Where it  
tends to be a bit dodgy is in the leading edge stuff: DSML, ldap  
controls and so on - but they improve with time, and they're actively  
developed by the Sun folks.

We have a simple JNDI provider for DSML that ships with JX and can be  
used stand alone, and it is easy to do similar things with other  
protocols (e.g. SPML), so the JNDI architecture does work, even if it  
is ornate.

JXplorer is built to allow different providers however - so if Apache  
DS decided to use a 'straight LDAP' library, we could rejig JX to use  
that as well, which could be neat, and would probably improve  
performance a fair bit.

However, don't underestimate the amount of guff that is in the  
current JNDI implementation... there's a bunch of work in there, and  
I'm not sure the other LDAP implementations have all the bells and  
whistles that JNDI does (they might - I honestly don't know :-) ).

So in summary: JNDI works, is a bit slow and complex, includes a  
bunch of security stuff, and ships standard with Java.  Other things  
may be faster and simpler, but may not be as complete...

    cheers,

        Chris

Mime
View raw message