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
application.
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. ;)
Trustin
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
