On 9/4/06, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Trustin Lee a écrit :

> Hi,
> Yes, I know this is a very radical approach, but I think this is
> mandatory to accelerate our development.
> JNDI is an abstraction API for all kinds of directory services.  LDAP
> is a part of the list.  From my experience, JNDI is not really the
> best API to access an LDAP server.  It can access the LDAP server, but
> not gives us the best convenience from the viewpoint of the API user.
> And we're using JNDI Name and DirContext interface to program our
> internals.  That's why we need a new API which perfectly fits into
> LDAP.  By doing that, we can program our interceptors and partitions
> more easily mapped into LDAP operations rather than JNDI operations.

The beauty of LDAP is that you can work with JNDI, Novelm API  (jldap :
http://www.openldap.org/jldap/ ) or even our own new API. We can keep the
JNDI approach, because it's common to many application, and dropping it
would be seen a little bit questionnable by our current users (I'm
thinking of Geronimo)

My idea is not just dropping but probiding a bridge (JNDI provider which wraps our own API).  So it should be OK.

> Of course, this change will take away the advantage of embedded mode
> unless we spend more time to create a bridge between JNDI and our
> API.  But I think our primary concern is to provide a high quality
> LDAP server whose internals are highly optimized for LDAP, not to
> provide a JNDI embeddable LDAP server.

We can provide both, in my opinion. JNDI is an interface...

Exactly.  I am just talking about the priority.

> 3. Support an embedded mode
>    * But who will ever use DNS or other services without LDAP
> provider?  The only advantage of the embedded access is the small
> performance gain which might not be that important in distributed
> directory services.

We really need this embeded mode. Many application will benefit from it
: no more complicated firwall configuration to let LDAP go through, no
more need to start the server before the application, etc. It's a little
bit like Jetty. Sometime, it's better to embrace everything in a simple

Well, if two run in the same machine, the client will use a loopback device to connect to the server, so firewall shouldn't be that much a problem.  I agree with you that embedded mode is useful, but we can still run both in the same VM and use loopback device.  Direct method invocation can come later.

> Was this too radical? :)

No, not too much ... I thought you would propose to switch to C# (I
would called it a revolution then :)

Yeah Glasgow team ported MINA to C# a little bit, so we can do that when it's ready. ;)

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6