From dev-return-35326-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Oct 13 08:04:05 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 31797 invoked from network); 13 Oct 2010 08:04:04 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Oct 2010 08:04:04 -0000 Received: (qmail 8784 invoked by uid 500); 13 Oct 2010 08:04:04 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 8570 invoked by uid 500); 13 Oct 2010 08:04:03 -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 8563 invoked by uid 99); 13 Oct 2010 08:04:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Oct 2010 08:04:02 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.214.178] (HELO mail-iw0-f178.google.com) (209.85.214.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Oct 2010 08:03:55 +0000 Received: by iwn9 with SMTP id 9so59159iwn.37 for ; Wed, 13 Oct 2010 01:03:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.4.211 with SMTP id 19mr3970008ict.56.1286957014127; Wed, 13 Oct 2010 01:03:34 -0700 (PDT) Sender: mail@stefan-seelmann.de Received: by 10.231.34.199 with HTTP; Wed, 13 Oct 2010 01:03:34 -0700 (PDT) In-Reply-To: <4CB50001.5010700@gmail.com> References: <4CB50001.5010700@gmail.com> Date: Wed, 13 Oct 2010 10:03:34 +0200 X-Google-Sender-Auth: QpAddHA0BmzB8HY2xohRc0Wug8o Message-ID: Subject: Re: Question about the configuration layout From: Stefan Seelmann To: Apache Directory Developers List , elecharny@apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi Emmanuel, On Wed, Oct 13, 2010 at 2:40 AM, Emmanuel Lecharny wr= ote: > =C2=A0Hi guys, > > as I was writing the configuration documentation, based on the way we > initialize the server, I went through the objectClasses we use to define = the > configuration for each element. That raised a question in my mind : > - why don't we link the elements together ? > > Right now, we expect some code to put the glue between those elements (ie > teh LdapServer OC does not contain any AT defining the DS to use, the DS > does not contain the list of Partitions it uses, etc). Wouldn't it be bet= ter > to add some AT in each elements to completely define, say, the LdapServer > configuration from the LdapServer entry, following the contained ATs ? I'd say it depends on the kind of relationship of those elements. If the relationship is a composition (i.e. the nested element can't live without the wrapping element) then we should use a hierarchical mapping. In that case an attribute in the parent entry that contains a DN pointing to the child entry should be avoided because of duplicate information. > One more thing : we should probably define an Abstract ads-oc OC containi= ng > the 'description' and 'ads-enabled' elements, which are present in all th= e > OCs ? I propose such an OC to handle those informations : > > *A[ads-base] > =C2=A0m-may: description > =C2=A0m-may: ads-enabled +1 > I have gathered all the existing OC with there MAY and MUST ATs, and list= ed > them here. The A[xxx] notation describes an ABSTRACT OC. The --> notation > defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that = OC1 > is the SUP in OC2). The * notation means that we may have from 0 to N > distinguishedName in an AT. The ATs pointing to other ads OCs are also > noted. > > With a little effort, I also think that reading such a hierarchy, we coul= d > automatically generate the beans using introspection, instead of writing = a > reader for each of those elements. My idea here was to use a persistence framework, like DataNucleus that is an JDO implementation. But I guess that's not so easy because when reading the config we only have the raw partition. Kind Regards, Stefan