Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 6687 invoked from network); 3 Sep 2009 14:14:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Sep 2009 14:14:41 -0000 Received: (qmail 22529 invoked by uid 500); 3 Sep 2009 14:14:41 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 22471 invoked by uid 500); 3 Sep 2009 14:14:40 -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 22461 invoked by uid 99); 3 Sep 2009 14:14:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Sep 2009 14:14:39 +0000 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=HTML_MESSAGE,SPF_PASS,SUBJECT_FUZZY_TION X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.210.187 as permitted sender) Received: from [209.85.210.187] (HELO mail-yx0-f187.google.com) (209.85.210.187) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Sep 2009 14:14:30 +0000 Received: by yxe17 with SMTP id 17so1100528yxe.9 for ; Thu, 03 Sep 2009 07:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Qe9WVeaRP6RanGM0IAIgHCu7GI8XG4kDbdYqc4DmTNQ=; b=BENxW375g/xpesuxEteUY41JKOZ2QnYIjXNDzeyO+a3TV2lHRNlLmfLL229c6V23KZ 19MxJuDU6LjKA2OKSgX5nL6wZ2ZWCt47ExmFxLQeUyziphXVPNpUbwKIL8JB6pFsOvei SDAbu9Tts08LtkxPsX/a9uyR2fmH4QQLtG7e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nMCcYlUMvKgTbkWEulqXr+a0l0llK+/pZ0IQ0rN+JEGUT66QMeXBgNvW1w2GirvrmT xI4t+uIfmZkSlF/enGyWXdz7s0Wr9oLcYa5hYRKcH5ASgLzHAKgnpVT5QzHp8y3Gd87r +Ktj9YL5ftM9wHEsAeoucFymw/rUrpQZt3htg= MIME-Version: 1.0 Received: by 10.100.74.21 with SMTP id w21mr3309701ana.165.1251987249344; Thu, 03 Sep 2009 07:14:09 -0700 (PDT) In-Reply-To: <4A9FB563.1080007@nextury.com> References: <4A9FABF2.5060803@nextury.com> <4A9FAF92.207@gmail.com> <4A9FB563.1080007@nextury.com> Date: Thu, 3 Sep 2009 17:14:09 +0300 Message-ID: Subject: Re: [Partition refactoring] Some proposals From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=001636b2b0c642b0980472acff0d X-Virus-Checked: Checked by ClamAV on apache.org --001636b2b0c642b0980472acff0d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 3, 2009 at 3:24 PM, Emmanuel Lecharny wrote: > Alex Karasulu wrote: > >> On Thu, Sep 3, 2009 at 2:59 PM, Kiran Ayyagari > >wrote: >> >> >> >>> Hi guys, >>> >>> >>>> right now, the Partition interface is used in two places : >>>> - as the interceptor chain entry point >>>> - as the facade for the specific backends (JDBM, LDIF, Oracle...) >>>> >>>> We are using the same interface in both case. >>>> >>>> What about defining two different interfaces ? One for the chain, one >>>> for >>>> the backend ? >>>> >>>> >>>> >>> +1 >>> >>> >>> >> >> Don't know for sure. Need to think a bit more about this. What specific >> entry point into the chain are you citing as using the Partition >> interface? >> I thought we used LdapSession which has similar methods yet adapted to >> deal >> with session related concerns. >> >> LdapSession is the adaptation of Partition that you're looking for I >> think. >> >> > Let me bit more precies. We have a CoreSession which uses an > OperationManager which pushes the operation into the InterceptorChain which > calls the NexusPartition method. Pfeww... > > This is this NexusPartition I suggest to be the base interface, and when we > hit the backend, we use an extended interface. > > Is it more clear ? > > Yep much clearer now. Yes I agree that there's some improvements to be made on the relationship between NexusPartition and Partition especially now that several things have shifted in the architecture of the server. I know we have remnants of crap that still plagues these interfaces. This is a great time to eradicate them! >> >> >>> >>> >>>> The chain interface (ie, Partition, to keep the existing name), will >>>> carry >>>> the operations (add, delete, search...), the other interface, named >>>> BackendPartition, which expose a bit more methods, like the sync() >>>> method, >>>> get/set Id, get/set SuffixDn, etc. >>>> >>>> Does it make sense to you ? >>>> >>>> >>>> >>>> >>> yeap, and one more thing is to change the BTreePartition class name too. >>> (I somehow feel that it doesn't sound like a generic base class) >>> >>> >>> >>> >> I agree. I think this is a base XdbmPartition implementation really. >> >> > Then we have to define it. We can rename the BTreePartion to be > XdbmPartition > > Sounds good to me. Regards, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org --001636b2b0c642b0980472acff0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 3, 2009 at 3:24 PM, Emmanuel= Lecharny <ele= charny@apache.org> wrote:
Alex Karasulu wrote:
On Thu, Sep 3, 2009 at 2:59 PM, Kiran Ayyagari <ayyagarikiran@gmail.com>wrote:<= br>
=A0
=A0Hi guys,
=A0 =A0
right now, the Partition interface is used in two places :
- as the interceptor chain entry point
- as the facade for the specific backends (JDBM, LDIF, Oracle...)

We are using the same interface in both case.

What about defining two different interfaces ? One for the chain, one for the backend ?

=A0 =A0 =A0
+1

=A0 =A0

Don't know for sure. Need to think a bit more about this. =A0What speci= fic
entry point into the chain are you citing as using the Partition interface?=
I thought we used LdapSession which has similar methods yet adapted to deal=
with session related concerns.

LdapSession is the adaptation of Partition that you're looking for I th= ink.
=A0
Let me bit more precies. We have a CoreSession which uses an OperationManag= er which pushes the operation into the InterceptorChain which calls the Nex= usPartition method. Pfeww...

This is this NexusPartition I suggest to be the base interface, and when we= hit the backend, we use an extended interface.

Is it more clear ?



Yep much clearer now.=A0 Yes I agree that t= here's some improvements to be made on the relationship between NexusPa= rtition and Partition especially now that several things have shifted in th= e architecture of the server.=A0 I know we have remnants of crap that still= plagues these interfaces.=A0 This is a great time to eradicate them!


=A0
=A0 =A0
The chain interface (ie, Partition, to keep the existing name), will carry<= br> the operations (add, delete, search...), the other interface, named
BackendPartition, which expose a bit more methods, like the sync() method,<= br> get/set Id, get/set SuffixDn, etc.

Does it make sense to you ?


=A0 =A0 =A0
yeap, and one more thing is to change the BTreePartition class name too. (I somehow feel that it doesn't sound like a generic base class)


=A0 =A0
I agree. =A0I think this is a base XdbmPartition implementation really.
=A0
Then we have to define it. We can rename the BTreePartion to be XdbmPartiti= on



Sounds good to me.=A0

Regards,
<= /div>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory = Server :: http://directory.apache.o= rg
Apache MINA :: http://mina.apache.org

--001636b2b0c642b0980472acff0d--