Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates
 64.233.184.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=pBlWOa0qeI63dedYdV1Kq1R74Byv1zXHRrmMjblCK3c53PTOHdQpNSClBUv1c/rm8JZ9rfhCRIKu4Bxe1WTfjcDheJ80SfG/lkZUWJdvZb64l3PyON1D6JNFYxFpA0KV2V5RomBowCMn23vtSqnE94DBEyXayDr60AXgC7eKUOo=
Message-ID: <a32f6b020707181212h2490e07ds2e7c4c78d786a6cd@mail.gmail.com>
Date: Wed, 18 Jul 2007 15:12:17 -0400
From: "Alex Karasulu" <akarasulu@apache.org>
Sender: akarasulu@gmail.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [ApacheDS] [CiDIT] Discussion
In-Reply-To: <43b026c70707180952v11c42c71ue7e20e0dad035ed9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_124272_2082691.1184785937480"
References: <a32f6b020707152003t684f4a0ibb15d50d58d1556c@mail.gmail.com>
	 <5F70BBD0-BC5F-46D2-B98D-D4CC23AF5C50@yahoo.com>
	 <a32f6b020707172015i51f4d7dfl3646be37805ada62@mail.gmail.com>
	 <43b026c70707172036o3d30cd6bi77e918012b96b3a1@mail.gmail.com>
	 <a32f6b020707172116s4f90eccfib5092533321f510b@mail.gmail.com>
	 <A715526F-2EC1-44BE-B188-53375B42DA38@yahoo.com>
	 <43b026c70707180952v11c42c71ue7e20e0dad035ed9@mail.gmail.com>

------=_Part_124272_2082691.1184785937480
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/18/07, Chris Custine <ccustine@apache.org> wrote:
>
> For what its worth, I think we are all actually talking about the same
> thing here, but we have divergent opinions on the implementation.  These are
> good discussions and hopefully they will bring clarity and consensus.


I agree. We're just not communicating as efficiently as we could.  There's
also
a lot of stuff to cache in the head while talking about this stuff.

I think we should go forward with aims we can agree on immediately.  Like
for example
removing the initialization code from within the server which uses these
configuration beans
into builder classes while documenting and communicating our ideas.  Also
we're going to
start to see clear extension points in the server by doing this.  It'll be
fun.

Then we can step back to think of how we can store configuration information
in the DIT that
is conducive to using this information with Spring or OSGi while still
supporting an optional
on disk server.xml based override.

Let's take it one piece at a time.  This initiative will be ongoing as we do
many other things.

Alex

------=_Part_124272_2082691.1184785937480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 7/18/07, <b class="gmail_sendername">Chris Custine</b> &lt;<a href="mailto:ccustine@apache.org">ccustine@apache.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For what its worth, I think we are all actually talking about the same thing here, but we have divergent opinions on the implementation.&nbsp; These are good discussions and hopefully they will bring clarity and consensus.</blockquote>
<div><br>I agree. We&#39;re just not communicating as efficiently as we could.&nbsp; There&#39;s also<br>a lot of stuff to cache in the head while talking about this stuff. <br><br>I think we should go forward with aims we can agree on immediately.&nbsp; Like for example
<br>removing the initialization code from within the server which uses these configuration beans <br>into builder classes while documenting and communicating our ideas.&nbsp; Also we&#39;re going to<br>start to see clear extension points in the server by doing this.&nbsp; It&#39;ll be fun.
<br><br>Then we can step back to think of how we can store configuration information in the DIT that<br>is conducive to using this information with Spring or OSGi while still supporting an optional<br>on disk server.xml based override.
<br><br>Let&#39;s take it one piece at a time.&nbsp; This initiative will be ongoing as we do many other things.<br><br>Alex<br></div><br></div><br>

------=_Part_124272_2082691.1184785937480--