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 chris.custine@gmail.com
 designates 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth;
        b=rvXmimHI+A7pjlGsC4SuazDMsgaz8jyXTC/qs6Oc2I0rn8nUgFhJQUM2SEOlCbjK4c1fHByXO6jycrgb+/c+FWExOngT724Pflr/pi9t6SxxXMWxlQVYyBTIVQvpavzQcGGzpFQbyGgaOsLZgbJaJ0EdbeXwbPui1cWFRiP6SUE=
Message-ID: <43b026c70707112227v5cd6f331h2fca8da7d0814ba0@mail.gmail.com>
Date: Wed, 11 Jul 2007 23:27:59 -0600
From: "Chris Custine" <ccustine@apache.org>
Sender: chris.custine@gmail.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Spring config / Config in DIT
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_12724_32447981.1184218079623"

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

This is basically a response to some of the other threads regarding
server.xml and Config in DIT, but I don't want to derail those threads if
this turns out to be a stupid idea.

I have been thinking about this for a while, and I have to admit that I am
one of the guys that likes Spring and the xml config files.  Because of that
I have been thinking about possible interim steps so that we can get a good
grip on the needs and wants of the users while still solving some of our
internal problems that we want to address in the short term.  Based on the
recent threads about this topic, I get the distinct feeling that we might be
underestimating the affect this subject has as far as user impact and user
preferences and stand a good chance of irritating some people.

My latest idea seems really obvious the more I think about it...  For the
time being, why don't we just move towards storing the server.xml in its
entirety as a string attribute under ou=system somewhere and restructure the
startup sequence to properly read and load the Spring context from there?
This sounds crazy, but bear with me for a moment...  This would give us the
ability to "configure in DIT" so to speak, but would also expose some really
interesting options for remote configuration, like modifying the current
Apache DS Configuration plugin that Pierre-Arnaud has already written to
just read from and save to the server it is currently connected to.  We
could also do an interceptor or something similar on the server to write the
file out to disk after a remote edit and allow a startup option or quick
command line script to load a new file after you edit it in vi or similar.
This CLI could even put the data directly to the JDBM tables so that you can
make edits without the server running.

I have a couple of reasons for bringing this to the table.  First of all, I
am one of those dirty, sadistic perverts that likes editing xml files by
hand as opposed to many other forms of config...  xml is like a second
language to me  :-)

Second and most importantly for ApacheDS, is that an approach like this will
give us a great short term benefit of remote config and admin capability,
without all of the work.  The server config editor that PAM wrote looks
fantastic to me and (hopefully) we can just extend the concept and hack it
to do what is needed for this without re-writing all of it.  This way we can
do the Config in DIT in an incremental fashion and possibly save some grief
that we may encounter later.  We will also be able to move on more quickly
to more serious tasks and implement high visibility features.

I am sure there are some technicalities that may be obstacles to this
idealistic approach, but I have had worse ideas, so I thought I would bring
it up and present it.  What do you guys think?

Thanks,
Chris

------=_Part_12724_32447981.1184218079623
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is basically a response to some of the other threads regarding server.=
xml and Config in DIT, but I don&#39;t want to derail those threads if this=
 turns out to be a stupid idea.<br><br>I have been thinking about this for =
a while, and I have to admit that I am one of the guys that likes Spring an=
d the xml config files.&nbsp; Because of that I have been thinking about po=
ssible interim steps so that we can get a good grip on the needs and wants =
of the users while still solving some of our internal problems that we want=
 to address in the short term.&nbsp; Based on the recent threads about this=
 topic, I get the distinct feeling that we might be underestimating the aff=
ect this subject has as far as user impact and user preferences and stand a=
 good chance of irritating some people.
<br><br>My latest idea seems really obvious the more I think about it...&nb=
sp; For the time being, why don&#39;t we just move towards storing the serv=
er.xml in its entirety as a string attribute under ou=3Dsystem somewhere an=
d restructure the startup sequence to properly read and load the Spring con=
text from there?&nbsp; This sounds crazy, but bear with me for a moment...&=
nbsp; This would give us the ability to &quot;configure in DIT&quot; so to =
speak, but would also expose some really interesting options for remote con=
figuration, like modifying the current Apache DS Configuration plugin that =
Pierre-Arnaud has already written to just read from and save to the server =
it is currently connected to.&nbsp; We could also do an interceptor or some=
thing similar on the server to write the file out to disk after a remote ed=
it and allow a startup option or quick command line script to load a new fi=
le after you edit it in vi or similar.&nbsp; This CLI could even put the da=
ta directly to the JDBM tables so that you can make edits without the serve=
r running.
<br><br>I have a couple of reasons for bringing this to the table.&nbsp; Fi=
rst of all, I am one of those dirty, sadistic perverts that likes editing x=
ml files by hand as opposed to many other forms of config...&nbsp; xml is l=
ike a second language to me&nbsp; :-)&nbsp;=20
<br><br>Second and most importantly for ApacheDS, is that an approach like =
this will give us a great short term benefit of remote config and admin cap=
ability, without all of the work.&nbsp; The server config editor that PAM w=
rote looks fantastic to me and (hopefully) we can just extend the concept a=
nd hack it to do what is needed for this without re-writing all of it.&nbsp=
; This way we can do the Config in DIT in an incremental fashion and possib=
ly save some grief that we may encounter later.&nbsp; We will also be able =
to move on more quickly to more serious tasks and implement high visibility=
 features.
<br><br>I am sure there are some technicalities that may be obstacles to th=
is idealistic approach, but I have had worse ideas, so I thought I would br=
ing it up and present it.&nbsp; What do you guys think?<br><br>Thanks,<br>C=
hris
<br>

------=_Part_12724_32447981.1184218079623--