From dev-return-13421-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Mon Sep 04 08:05:23 2006 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 48528 invoked from network); 4 Sep 2006 08:05:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Sep 2006 08:05:23 -0000 Received: (qmail 60445 invoked by uid 500); 4 Sep 2006 08:05:22 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 60225 invoked by uid 500); 4 Sep 2006 08:05:22 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 60214 invoked by uid 99); 4 Sep 2006 08:05:22 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Sep 2006 01:05:22 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.166.177 as permitted sender) Received: from [64.233.166.177] (HELO py-out-1112.google.com) (64.233.166.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Sep 2006 01:05:21 -0700 Received: by py-out-1112.google.com with SMTP id d80so2522901pyd for ; Mon, 04 Sep 2006 01:05:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=U9NkcgwYlwAp19pk2r2RwX3ot+veitW2Umc3iLHrBABapS0NuFMeBjP5WzLMpE53M7/7/2qdcYdgLkJbrNOYwb6iSJhN3JEI5/scUw7l7p8wZzYg3GwGdUXM09FNQLqOVdJ0HI457l9XgdiRvVRCr/h9bmKSCB4QtVv0mNJXwXs= Received: by 10.35.63.2 with SMTP id q2mr9586241pyk; Mon, 04 Sep 2006 01:05:00 -0700 (PDT) Received: by 10.35.68.13 with HTTP; Mon, 4 Sep 2006 01:04:59 -0700 (PDT) Message-ID: <768dcb2e0609040104p30483361q198c616f397199af@mail.gmail.com> Date: Mon, 4 Sep 2006 17:04:59 +0900 From: "Trustin Lee" To: "Apache Directory Developers List" , elecharny@iktek.com Subject: Re: [ADS 2.0] Detach JNDI from ApacheDS In-Reply-To: <44FBD340.6070800@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38271_1195934.1157357099996" References: <768dcb2e0609032040o2e776c9fm1118413ddc7ebaeb@mail.gmail.com> <44FBD340.6070800@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_38271_1195934.1157357099996 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 9/4/06, Emmanuel Lecharny wrote: > > Trustin Lee a =E9crit : > > > 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 --=20 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 ------=_Part_38271_1195934.1157357099996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 9/4/06, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Trustin Lee a =E9crit :

> Hi,
>
> Yes, I know this is= a very radical approach, but I think this is
> mandatory to accelera= te our development.
>
> JNDI is an abstraction API for all kind= s 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 acc= ess 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<= br>> internals.  That's why we need a new API which perfectly = fits into
> LDAP.  By doing that, we can program our interc= eptors and partitions
> more easily mapped into LDAP operations rather than JNDI operation= s.

The beauty of LDAP is that you can work with JNDI, Novelm API&nbs= p; (jldap :
http://www.o= penldap.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 bi= t 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<= br>> 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 dis= tributed
> directory services.

We really need this embeded mod= e. Many application will benefit from it
: no more complicated firwall configuration to let LDAP go through, no<= br>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 firewal= l shouldn't be that much a problem.  I agree with you that embedded mo= de is useful, but we can still run both in the same VM and use loopback dev= ice.  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. ;)<= br>

Trustin
--
what we call human nature i= s actually human habit
--
http://gleamynode.net/
= --
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 5= 44D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC = 0255 ECA6 ------=_Part_38271_1195934.1157357099996--