Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 95138 invoked from network); 14 Sep 2010 08:27:42 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Sep 2010 08:27:42 -0000 Received: (qmail 21076 invoked by uid 500); 14 Sep 2010 08:27:41 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 20868 invoked by uid 500); 14 Sep 2010 08:27:39 -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 20861 invoked by uid 99); 14 Sep 2010 08:27:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 08:27:38 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-qy0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 08:27:33 +0000 Received: by qyk30 with SMTP id 30so2836334qyk.16 for ; Tue, 14 Sep 2010 01:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ThlGeCaKYEga6LGAyBNRlEoSjp8iqFJdl/sjeewDBg4=; b=fv+hTVKFu/w2azFjcrKzETKa3momGwXMBZB15PLQ+lNuAHgG4viwakDvtCRm//bu1p 5mCmEcIDHyzphxZXcLJfunWwZepnzho9r444Q+ryv5rWEMDHxitRqLsx3JaLTXoeV0+5 JIdFhaM9FGhC/iDj0E1hTyqjbCxl0SO5uIHJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=XqIa0r7qE3ulnmZU1tD/3zYbTMW/bqPGbDdPrLicFsL3GB89bjfqZSMV2z2lzaer6n oTlEvDAY46AH6Ljmue0bmQjREbJjuPkcYPAqGt6rHw0NbyE3YpD7WCEmYSbS2Hk6MjpC Nfx2/fgZ1xvgH9fy9f0GuwXV7n/rd/TOsfFC0= MIME-Version: 1.0 Received: by 10.224.73.106 with SMTP id p42mr954354qaj.176.1284452829817; Tue, 14 Sep 2010 01:27:09 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.229.248.72 with HTTP; Tue, 14 Sep 2010 01:27:09 -0700 (PDT) In-Reply-To: References: <4C8E9A5F.2090908@gmail.com> <4C8EA55C.3030401@gmail.com> Date: Tue, 14 Sep 2010 11:27:09 +0300 X-Google-Sender-Auth: 2mDzKlMTu_3vGKZh9O_5kdD-Og0 Message-ID: Subject: Re: Shared refactoring proposal From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=00c09f88cd8aa6ee4b049033fac4 --00c09f88cd8aa6ee4b049033fac4 Content-Type: text/plain; charset=ISO-8859-1 +1 on the MINA decoupling and the package + module renaming to ldap-api. But could you give us a detailed idea of what this will look like in terms of the package space. I ask this because it would be nice to have the ldap-api isolated so that it can be a simple OSGi bundle that can be reused and bound to implementation bundles at runtime for connections etc. Regards, On Tue, Sep 14, 2010 at 1:27 AM, Kiran Ayyagari wrote: > On Tue, Sep 14, 2010 at 3:57 AM, Emmanuel Lecharny > wrote: > > On 9/13/10 11:44 PM, Kiran Ayyagari wrote: > >> > >> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny > >> wrote: > >>> > >>> * asn1-codec should be merged with the client-api, and all the parts > that > >>> are related to MINA (the best would be to abstract completely this part > >>> from > >>> MINA, in order to be able to switch the network layer) > >> > >> this abstraction layer gets complicated as we dig through, IMHO I would > >> say > >> let us leave it as it is, we are not gonna change our network layer > >> anyway in the near > >> future. We are happy with MINA, aren't we? > > > > Let me explain what I see as an issue : currently, shared-ldap depends on > > MINA even if we don't use MINA at all (like Studio which is currently > using > > JNDI). Why would someone using only this part has to embed MINA too ? > > > > Also the only link we have with mina here is because the > LdapProtocolEncoder > > is implementing a MINA class to encode a message. Nowhere in shared do we > > call the encode method. > > > > This is what I'd like to get rid of. > ahhh, I see where the issue is, I had the same problem when I wanted > to implement a new > LdapConnection with a different transport without using MINA but I > ended up bunding MINA > dependency too. > > +1 for a abstraction layer > > Kiran Ayyagari > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --00c09f88cd8aa6ee4b049033fac4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on the MINA decoupling and the package + module renaming to ldap-api. Bu= t could you give us a detailed idea of what this will look like in terms of= the package space. I ask this because it would be nice to have the ldap-ap= i isolated so that it can be a simple OSGi bundle that can be reused and bo= und to implementation bundles at runtime for connections etc.

Regards,

On Tue, Sep 14, 2= 010 at 1:27 AM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Tue, Sep 14, 2010 at 3:57 AM, Emmanuel= Lecharny <elecharny@gmail.com> wrote:
> =A0On 9/13/10 11:44 PM, Kiran Ayyagari wrote:
>>
>> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny<elecharny@gmail.com>
>> =A0wrote:
>>>
>>> * asn1-codec should be merged with the client-api, and all the= parts that
>>> are related to MINA (the best would be to abstract completely = this part
>>> from
>>> MINA, in order to be able to switch the network layer)
>>
>> this abstraction layer gets complicated as we dig through, IMHO I = would
>> say
>> let us leave it as it is, we are not gonna change our network laye= r
>> anyway in the near
>> future. We are happy with MINA, aren't we?
>
> Let me explain what I see as an issue : currently, shared-ldap depends= on
> MINA even if we don't use MINA at all (like Studio which is curren= tly using
> JNDI). Why would someone using only this part has to embed MINA too ?<= br> >
> Also the only link we have with mina here is because the LdapProtocolE= ncoder
> is implementing a MINA class to encode a message. Nowhere in shared do= we
> call the encode method.
>
> This is what I'd like to get rid of.
ahhh, I see where the issue is, I had the same problem when I w= anted
to implement a new
LdapConnection with a different transport without using MINA but I
ended up bunding MINA
dependency too.

+1 for a abstraction layer

Kiran Ayyagari



--
Alex KarasuluMy Blog :: http://www.jrolle= r.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--00c09f88cd8aa6ee4b049033fac4--