directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: [ADS 2.0] Detach JNDI from ApacheDS
Date Mon, 04 Sep 2006 08:04:59 GMT
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
> 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

Mime
View raw message