From dev-return-34894-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Aug 31 06:18:48 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 88154 invoked from network); 31 Aug 2010 06:18:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 31 Aug 2010 06:18:48 -0000 Received: (qmail 6595 invoked by uid 500); 31 Aug 2010 06:18:48 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 6388 invoked by uid 500); 31 Aug 2010 06:18:45 -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 6380 invoked by uid 99); 31 Aug 2010 06:18:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Aug 2010 06:18:44 +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, 31 Aug 2010 06:18:39 +0000 Received: by qyk30 with SMTP id 30so4333977qyk.16 for ; Mon, 30 Aug 2010 23:18:19 -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=JTppXgtk66PZn9rGgKKTsriECHNMDKM9fmfzYgMRFY4=; b=ETJ914xksA3WmM+upxFPdE03hRs+HXg9uwPb8xmUn5gmk1unpopFMwzEgpQbpaCiwJ AdPnhYsWBiPdsB4xiDJCI6+5p5q2C0rnlsK88YHB+NTkF9WIaX6Xf0Mc8dsRdx7bhl1b 0wfMq70lqJVf6IUsvZoBihjQcw91RU/sHxjLc= 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=DrBpEqdDGv9uSMxn1qEx1uXra3QzM1SbeVt8SXL1dFIb5TTpHuvn0U3Ny02dzgNn0Y azm+9p+O72aYNBWSyWdbarSbmau6D0eVWQftRwKBT/KurYzlp392W0G1ImTlXNkWytqt Q8R5EHxLs4xzLFf+ZRses67EZK9OAn/EcvsNs= MIME-Version: 1.0 Received: by 10.229.2.42 with SMTP id 42mr3787646qch.235.1283235498813; Mon, 30 Aug 2010 23:18:18 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.229.239.203 with HTTP; Mon, 30 Aug 2010 23:18:18 -0700 (PDT) In-Reply-To: <4C56D742.70002@gmail.com> References: <4C56D742.70002@gmail.com> Date: Tue, 31 Aug 2010 09:18:18 +0300 X-Google-Sender-Auth: Utr2IVjfu2A_Pu_4ClLzqwy3x8o Message-ID: Subject: Re: About Partition, AdministrativePoints and the whole universe... From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=0014853c972e11e913048f188c9c --0014853c972e11e913048f188c9c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 2, 2010 at 5:33 PM, Emmanuel Lecharny wrote: > Hi guys, > > as I'm slowly refactoring the data structure we use to manage > NamingContexts, I just realized that we may have a way to handle > encapsulated partitions... > > One of the Graal we were chasing was the possibility to define encapsulated > partitions. Let me give you an example : > > if we define dc=example,dc=org as a naming context, then we have to define > a dedicated partition (be it JDBM, LDIF, HBase, in-memory, SQL-based). > That's good, but if we want to define a sub-partition for, say > ou=apache,dc=example,dc=org, we currenty can't. That means this ou=apache... > thing will be stored in the same backend than the partition it's defined > into (dc=example,dc=org). > > We also have some issue currently, like DIRSERVER_1517 : we can't move an > entry from one partition to another one (this is a bug) > > Yep that's certainly a bug. > Ok, how can we manage encapsulated partitions ? Here is one idea I had : > - what about leveraging the X500 administrative model ? We currently can > manage AccessControl, CollectoveAttribute, SubSchema (even if we don't > support it atm), TriggerExecution, so why not add a new role, the > PartitionLayout role which defines a new partition starting at the defined > Administrativepoint ? > > So a partition is a role, defining the storage, and all of it's > characteristics, using a subentry for that. Of course, a PL AP won't be an > Inner AP. We won't allow any subtree specification for this subentry, and > the base will always be the AP. It should work. > > Very interesting idea - I never thought or imagined using the X.500 admin model for this. However don't we need inner AP's if the point in the first place is to have nesting and the partition is rooted at the AP? > Now, a few more thoughts : the current partitions configuration is stored > into the ou=config partition (a LDIF partition). How can we continue using > this config partition in sync with the subentries ? What if subentries are > just aliases pointing to the config partition ? As we have to load all the > subentries at startup, it would be far easier to do that if they are stored > into the config partition. > > Yes this is a great idea. I agree with this approach at first sight. It would be much easier and faster to pull out the subentries from the configuration area but this creates some oddities though on second thought. We basically have subentries located under the configuration area but they are not subordinate to APs. Technically subentries should subordinate to APs according to implicit ditStructureRules built into the protocol. > Ok, those are just ideas, but I think it can fit well with the big picture. > > feel free to comment ! > > Very interesting thought but I think we need to think about this a bit more. I have also some ideas on implementing nested partitions and a new organization in the backend to partitions which will facilitate handling entry relocations across partitions as well as cross partition aliases. More to follow in the coming days. -- 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 --0014853c972e11e913048f188c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 2, 2010 at 5:33 PM, Emmanuel= Lecharny <elec= harny@gmail.com> wrote:
=A0Hi guys,

as I'm slowly refactoring the data structure we use to manage NamingCon= texts, I just realized that we may have a way to handle encapsulated partit= ions...

One of the Graal we were chasing was the possibility to define encapsulated= partitions. Let me give you an example :

if we define dc=3Dexample,dc=3Dorg as a naming context, then we have to def= ine a dedicated partition (be it JDBM, LDIF, HBase, in-memory, SQL-based). = That's good, but if we want to define a sub-partition for, say ou=3Dapa= che,dc=3Dexample,dc=3Dorg, we currenty can't. That means this ou=3Dapac= he... thing will be stored in the same backend than the partition it's = defined into (dc=3Dexample,dc=3Dorg).

We also have some issue currently, like DIRSERVER_1517 : we can't move = an entry from one partition to another one (this is a bug)


Yep that's certainly a bug.
<= div>=A0
Ok, how can we manage encapsulated partitions ? Here is one idea I had : - what about leveraging the X500 administrative model ? We currently can ma= nage AccessControl, CollectoveAttribute, SubSchema (even if we don't su= pport it atm), TriggerExecution, so why not add a new role, the PartitionLa= yout role which defines a new partition starting at the defined Administrat= ivepoint ?

So a partition is a role, defining the storage, and all of it's charact= eristics, using a subentry =A0for that. Of course, a PL AP won't be an = Inner AP. We won't allow any subtree specification for this subentry, a= nd the base will always be the AP. =A0It should work.


Very interesting idea - I never though= t or imagined using the X.500 admin model for this. However don't we ne= ed inner AP's if the point in the first place is to have nesting and th= e partition is rooted at the AP?
=A0
Now, a few more thoughts : the current partitions configuration is stored i= nto the ou=3Dconfig partition (a LDIF partition). How can we continue using= this config partition in sync with the subentries ? What if subentries are= just aliases pointing to the config partition ? As we have to load all the= subentries at startup, it would be far easier to do that if they are store= d into the config partition.


Yes this is a great idea. I agree with= this approach at first sight. It would be much easier and faster to pull o= ut the subentries from the configuration area but this creates some odditie= s though on second thought. We basically have subentries located under the = configuration area but they are not subordinate to APs. =A0Technically sube= ntries should subordinate to APs according to implicit ditStructureRules bu= ilt into the protocol. =A0
=A0
Ok, those are just ideas, but I think it can fit well with the big picture.=

feel free to comment !


Very interesting thought but I = think we need to think about this a bit more. I have also some ideas on imp= lementing nested partitions and =A0a new organization in the backend to par= titions which will facilitate handling entry relocations across partitions = as well as cross partition aliases. More to follow in the coming days.

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache = Directory Server :: http://director= y.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--0014853c972e11e913048f188c9c--