Emmanuel Lecharny 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)
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...
Yeah I think we can provide both. Trustin was referring to a bridge
before and I agree.
The LDAP protocol provider would not use this bridge however. It would
use the LDAP specific API instead.
Other protocol providers that back their information within ApacheDS can
use the JNDI bridge.
Here's my suggestion:
1. Change the DirectoryPartition and Interceptor interface to fit 1:1
to LDAP operations rather than JNDI operations.
* Core/ServerDirContext will be removed in this process.
* ServerStartupConfiguration should be merged into
StartupConfiguration and embedded mode should go away because we can
just disable the LDAP service later when OSGi is adopted.
This is a possible move. Alex ?
Yeah I think can. What I recommend is small refactorings to slowly
bring us towards this or a similar goal. First we can decouple the JNDI
provider from the core. We can also decouple the configuration from the
core as well. By doing these things we will arrive at a better
structure and then will have better vision to figure out what needs to
be done next.
2. Migrate to OSGi framework
* All protocol services will be provided as OSGi bundles and should
be plugged into ApacheDS dynamically. Because we don't have any
embedded JNDI provider, LDAP protocol connection to loopback device
will be used temporarilly.
Hmmm I don't know about this. I think these guys can use the bridge and
not have to go through the wire which would slow things down. Trustin
was this lookback thing related to conversations we had in the past over
ClassLoader issues and instances of the DirectoryServer? My memory is a
bit hazy here.
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.
Good point. At this point I'm not exactly sure on any one direction.
Sorry but I have not had a chance to think about 1.1 fully yet. I've
been so focused on making sure we get this 1.0 out the door.
Alex
